What the Linux Desktop Needs (OS Views) [LWN.net]

OS Views is running Kurt Pfeifle's opinion of what the Linux desktop needs. "I have mentioned it before, and I will repeat it here again: any commercial software vendor pondering to sell his product or service on the Linux platform is horrified by the complications he has to deal with."

to post comments

What the Linux Desktop Needs (OS Views)

Posted May 20, 2005 23:38 UTC (Fri) by lutchann (subscriber, #8872) [Link] (5 responses)

While many people agree with Mr Pfeifle about the need for better binary compatibility and packaging standards (I don't, though), his rousing battle cry misses the mark. In his editorial, he says, "The fate of the Linux desktop is tightly coupled" to the willingness of the Linux community to make efforts to accommodate commercial (and presumably closed-source) software vendors. This amounts to a thinly-veiled threat. "Unless you volunteers do what I say, I won't be able to make money off you!" Where's our motivation?

Rather than criticizing us for not understanding the needs of the commercial software market, I think Mr Pfeifle needs a clue about how to work with the open-source world.

What the Linux Desktop Needs (OS Views)

Posted May 21, 2005 0:16 UTC (Sat) by mmarq (guest, #2332) [Link] (1 responses)

" "The fate of the Linux desktop is tightly coupled" to the willingness of the Linux community to make efforts to accommodate commercial (and presumably closed-source) software vendors. This amounts to a thinly-veiled threat. "Unless you volunteers do what I say, I won't be able to make money off you!" Where's our motivation? "

I belive it hasen't anything to do with 'commercial vs free ', but with stable vs development. This 'commercial vs free' is just a smoke screen, it isn't real and it's hipocrytical at many points.

Can't i sell something that is completely GPLed ?... the problem is fragmentation due to differentiation by *features* instead of services.

Linux isn't a *platform* yet. Its a collection of tools and frameworks, whose major commercial parts are working very hard to keep it as a *constant flux* development paradigma, so they can extract value by *feature differentiation* because they have resources(lab and programmers) that much smaller competitors dont have.

So a rock solide *stable platform*, in the sense off lasting long time unchanged and apart of the development cicles and trees, is something we wont see in the next times, because the installed commercial partys in Linux world are affraid of losing control. LSB and other efforts are still going at a snail speed for a while. That in a sense isn't much different from Microsoft, bypassing the all for users nature of GPL to have an all for business nature like Microsoft.

Linux/OSS still as to fullfill many promessed achievements, pitty the barriers to enter are so big, specialy for small contenders like those in the article.

What the Linux Desktop Needs (OS Views)

Posted May 24, 2005 8:40 UTC (Tue) by minichaz (guest, #630) [Link]

"Linux isn't a *platform* yet"

And it never will be. Linux is a KERNEL.

This is a total non issue anyway if you simply choose to write your closed software for something like Redhat Enterprise Linux as companies like Oracle do. These distros are supported for 5 years and the APIs/ABIs remain static for all of that time.

So... Linux isn't a platform, GNU/Linux isn't a platform, RHEL and similar distros are platforms.

What the Linux Desktop Needs (OS Views)

Posted May 22, 2005 17:15 UTC (Sun) by kobserver (guest, #30087) [Link] (2 responses)

@lutchann:

FIRST:

You do not seem to have read Mr.Pfeifle's article at all, nor have you researched who Mr.Pfeifle is.

I have. Mr.Pfeifle is deeply involved with KDE (and has contributed much useful documentation to various Open Source Projects, such as Samba, CUPS, Linuxprinting.org and most recently FreeNX [http://www.osnews.com/story.php?news_id=8139]).

So he has some more clue about the topic than you seem to to imply.

SECOND:

Your quoting of his opinion piece is extremely distorting. He is not at all venting a "thinly-veiled threat".

Since he is himself involved in FOSS projects, he is talking to his peers. This is also underlined by the fact, that the piece first appeared in his blog [http://www.kdedevelopers.org/blog/418], some days before OSviews mirrored it.

THIRD:

Mr.Pfeifle "needs a clue about how to work with the open-source world"? Maybe rather one Mr. lutchann needs a clue about how to work with Google [http://www.google.com/search?q=%22Kurt+Pfeifle%22].

What the Linux Desktop Needs (OS Views)

Posted May 22, 2005 20:24 UTC (Sun) by lutchann (subscriber, #8872) [Link]

I did, in fact, Google for Mr Pfeifle's name before writing my above comment. While his background explains why he marginalizes the GNOME project and its substantial user base, who Mr Pfeifle is or his past contributions to open-source projects have no bearing on my criticism that making demands of the Linux community in support of proprietary software will get him nowhere. My point would still be valid had the piece been written by Richard Stallman or Linus Torvalds, although neither of them would ever predict that the success of Linux hinges on the support of commercial software vendors.

What the Linux Desktop Needs (OS Views)

Posted May 23, 2005 8:27 UTC (Mon) by philips (guest, #937) [Link]

Well, I'm sorry. But he really need a clue.

I've being in set-top-boxes business several times. You/he completely miss the point how it works.

[ The real problem with commercial guys that they overly lazy. And their beloved brute force programming methods just do not work with OSS. ]

You select components. You fix your software development requirements. And you do development. Time comes - you update yorself to newer version.

I had a brilliant example of such process, when company started development of their application for KDE1/Qt1. They have missed completely KDE2 - and customers signed-up for beta were need to use KDE1. Piece of cake with Linux: people just kept RedHat 6.x installed along with newer version of Linux. Then some time before release, KDE3 integration process started. And not that they have any huge problems with that either.

Version was release for Qt3 and tested on SuSE 8.0 with KDE 3.0.2. And customers were advised to use SuSE. And not that it bothered any customer.

Probably my knowledge is bit outdated. But from my time, the problem was RedHat: they never ever include releases in RHL - always latest greates pacthed CVS versions of libraries/application. That is pain. Fortunately SuSE was Okay on that issue.

P.S. Actually how hear complains that SuSE 9.x does as RHL - untested patched stuff right from CVS... :-/

P.P.S. And do not forget what actually Progeny Linux is all about. Never knew people using it, but custom distro is all what it is about. And Debian itself - I know prety much people still using Debian 2.2 - well that what I call stability.

What the Linux Desktop Needs (OS Views)

Posted May 21, 2005 0:44 UTC (Sat) by mmarq (guest, #2332) [Link] (22 responses)

" But they didn't go for Qt, despite its technological leadership. They did neither go for Gtk. Both, Qt and Gtk are a minority. The overwhelmingly big part of ISVs aiming for "platform independence" have embraced Java. There is a whole big ecosystem of Java programs out there. There is the big community that has formed around the Eclipse framework and plugin system.

How can we make these programs first class citizens in our desktop environment? "

That is one of the Linux/OSS/Unix very hiped but still undelevered promess.
Complete separation of GUI from the executable core implementation. Perhaps an IDL language in the form a XUL, that can speak a metatoolkit that will be the fundation of all futur toolkits, including Java, is a good idea. The big hurdle, miles high, is to disconnect pride and commercial interests for a little while, so that can happen. And even god knows that the traditional look & fell of Java applications, besides beying a little too slow, sucks so immensely that is a danger of one suffering strokes and drew abundantly while looking at it.

Overhead

Posted May 21, 2005 7:52 UTC (Sat) by eru (subscriber, #2753) [Link] (15 responses)

Complete separation of GUI from the executable core implementation. Perhaps an IDL language in the form a XUL, that can speak a metatoolkit that will be the fundation of all futur toolkits, including Java, is a good idea.

And would guarantee GUI applications be even slower and memory consuming than today's bloatware. Every level of indirection has an added cost in terms of CPU and memory usage.

Even today I feel that at some point the X11-based GUIs have taken a seriously wrong turn. The exes of single apps take up more space than, say, the entire version 2 of MS Windows, and run more slowly than it on hardware hundreds of times more powerful than what was available in 1980's.

Overhead

Posted May 21, 2005 16:44 UTC (Sat) by tjc (guest, #137) [Link]

Yes, I think you are right. There's very little work in progress on simpler alternatives, probably because there's very little motivation for such a thing. There's certainly no motivation on the part of commercial vendors.

Most larger free/open source software projects tend to get out of control after a while. I think about how nice KDE 1.x was, and how big and complicated 2.x/3.x became. Gnome tried to reign this in with version 2.x, but they somehow managed to eliminate a lot of features without reducing size or complexity.

Most small, simple applications tend to be written by single individuals, or small groups, but a lot of these are old and semi-maintained, or have bizarre user interfaces or other usability problems.

I think it's (past) time to embrace the "Third System Effect" in software design.

Overhead

Posted May 21, 2005 22:54 UTC (Sat) by mmarq (guest, #2332) [Link] (13 responses)

" And would guarantee GUI applications be even slower and memory consuming than today's bloatware...
...Even today I feel that at some point the X11-based GUIs have taken a seriously wrong turn. "

The same old whinning. Todays GPU are bigger than the CPU. Just look at the specs for playstation3, 1.8TFlops!!! http://www.tomshardware.com/hardnews/20050516_223209.html
And if that isn't enough then there is always the possibility of joing several GPU togheter !!! http://www.tomshardware.com/hardnews/20050520_153522.html

The problem is not bloat, but complexity. Because as graphics technologies got better Linux/OSS stayed behind because of a short sited 'hardware device driver policy' that caused Linux drivers drag behind, And even if there are drivers from the major vendors, Nvidia and ATI, they are not as good as the Windows counterpart, and worst those vendor make a pou-pou of the followed official kernel policy. For other vendors, why even bother to buy a $100 graphic board if you can only use $50, under Linux?!!

As to speed, the Mozilla interface with which i'm righting this comment, is not slow. If it's sloweer than Gnome or KDE, one hardly notice, and with something close to 1,8TFlops no one ever will. And a form of XUL can be optimized to work with C/C++ toolkits with a very minimal overhead... me thinks so.

So what is missing is *political* will, because the technical argument don't stick.

Overhead

Posted May 22, 2005 1:45 UTC (Sun) by zblaxell (subscriber, #26385) [Link]

"The same old whinning. Todays GPU are bigger than the CPU. Just look at
the specs for playstation3, 1.8TFlops!!"

I have a pet peeve: People who trivialize performance costs by quoting
only the _maximum_ performance capabilities of _the most recent_ hardware,
as if these numbers actually mean something.

The first part of the peeve is the assumption that I'm necessarily using
the very newest hardware, and operating it in its highest throughput mode.
I still have many machines in production that can barely manage a single
gigaflop at the peak of their performance, but I keep them because they
operate without error for years at a time. I also do a lot of
battery-powered computing, where keeping CPU throughput below 100 MIPS is
actually desirable because of the longer battery life.

A modern PC (e.g. a HT-capable P4 desktop) is made of three parts: Two
machines, each about 1/8 the size and power of a Commodore 64, that run at
3.2 GHz; a machine the size of an Amiga 500 that runs at half that speed,
and the rest of the machine which runs about 5-6 times slower.

Sure, you can add a few levels of indirection here and there in the
software, and it won't cost anything--that is, until the bloat exceeds a
"magic size" that forces the system to use hardware with a different
size/cost/performance tradeoff for its inner loops. Once that happens, it
makes much more sense to look at the _minimum_ performance numbers, since
that's all that will ever come out of the hardware.

Even worse, the minimum level of performance will bear all the same costs
as full performance. Data structure A might require a 3000mAh battery to
run for an hour, while data structure B (which is the same as A except
with a double-indirection feature) might require 7000mAh to run for an
hour, even though the application that manipulates the data structure runs
at the same speed.

End of rant. ;-)

One interesting (and somewhat counterintuitive) observation is that
systems where the application core and the user interface are strongly
separated actually have better performance in many cases than systems
where these two parts are tightly coupled. There is more latency when the
two systems communicate, but this can be offset by higher performance of
the two systems individually.

On the nature of bloat

Posted May 22, 2005 13:09 UTC (Sun) by eru (subscriber, #2753) [Link] (9 responses)

The same old whinning. Todays GPU are bigger than the CPU. Just look at the specs for playstation3, 1.8TFlops!!! http://www.tomshardware.com/hardnews/20050516_223209.html And if that isn't enough then there is always the possibility of joing several GPU togheter !!! http://www.tomshardware.com/hardnews/20050520_153522.html

Totally irrelevant to my complaint!

Actual graphics performance has almost never been a factor in the software I find bloated. They feel about equally bloated when running on Xvesa or on X with proper graphics acceleration. It is what happends in the data structures and code behind the visible elements that is problem. Unnecessary window repaints, operations that are O(n^2) when they could be O(log n), or O(n), too much memory used due to lazily-designed data structures and so on.

The problem is not bloat, but complexity. ...

Complexity is certainly part of the problem but not in the way you think. A word-processor from 2005 certainly has more features than a word processor from 1985, but not a hundred times more features. Yet it seems to use a hundred times more resources! Our field seems to delight in doing the same old thing using ever more resources, and calling it progress. Probably the only field of technology that does so.

One reason for this is that it is the user that supplies the required computing power, not the software author. Therefore the author has less incentive to save resources. In embedded device development where the software and hardware is often by the same vendor, you see less bloat, because the vendor has to balance the costs of both.

As to speed, the Mozilla interface with which i'm righting this comment, is not slow.

I, too, use Mozilla. Yes, it is tolerable on >500Mhz >128Mb machines, but still often feels sluggish at times on 600Mhz (as does Gnome and KDE). Given that kind of computing power, a browser should load and should operate instantly, with the only delays caused by network waits. Now imagine all GUI software written in XUL-like techniques. The memory footprint in everything on the desktop would grow, as would the CPU usage. The user upgrading to that system would find he has to get something like a twice more capable computer to retain the same facilities...

On the nature of bloat

Posted May 22, 2005 13:35 UTC (Sun) by dmaxwell (guest, #14010) [Link] (7 responses)

A big advance we're all missing here is that the costs associated with developing software have dropped. Yes, the layered high level toolkits introduce bloat and slowness. On the other hand, it means that you don't hav e to be an assembly language god to make a word processor. You don't need uber developers to create application stacks and they can be created relatively cheaply. Most of the increase in computing power we've seen has gone to making it possible for developers and system components to interact at higher and higher levels. If one wants to argue that it is time to reign in the madness, then I agree. We're going to multicore processors because we've hit a brick wall in processing speeds that has lasted for over a year. It also appears that 8GB is the practical limit of RAM for end user desktops with most people running 1GB or less. We can no longer assume that the machines coming down the pike will speed up applications for us.

On the nature of bloat

Posted May 23, 2005 4:24 UTC (Mon) by tjc (guest, #137) [Link] (6 responses)

Yes, the layered high level toolkits introduce bloat and slowness. On the other hand, it means that you don't hav e to be an assembly language god to make a word processor.

IMO the only good place to use a high level toolkit is for an application that has to be written quickly, changes frequently, has a short expected lifespan, or has a user base of limited size.

Word processors, on the other hand, do not change frequently, they have a long expected lifespan, and they are used by millions of people. Any increase in productivity on the development side is dwarfed in comparison to loss in productivity of millions of users sitting around waiting for the program to load. The more people use the application, and the longer it's in use, the worse it gets.

One probably doesn't need to be an ASM expert to write a good word processor, but ditching the high level toolkit would probably be a step in the right direction.

On the nature of bloat

Posted May 23, 2005 9:11 UTC (Mon) by pontus (guest, #3701) [Link] (4 responses)

In open source, we wouldn't even have good word processors etcetera without the high level toolkits, as there are simply not enough developers. If ditching the toolkit means we wouldn't have got the software we find useful (Mozilla, OpenOffice, Emacs), it's not at all a step in the right direction.

On the nature of bloat

Posted May 23, 2005 10:11 UTC (Mon) by eru (subscriber, #2753) [Link] (3 responses)

In open source, we wouldn't even have good word processors etcetera without the high level toolkits, as there are simply not enough developers.

Except for Emacs, those projects (Mozilla, OpenOffice) you mentioned basically first wrote their own GUI toolkit before doing the actual application! Ditto for Gimp and some others. Emacs started life without any GUI at all, it was grafted on later, and until fairly recently, the Emacs GUI used just the bare X11 facilities, no toolkit.

It seems to me your argument about the excessive amount of work involved does not hold water.

To be clear, I am not arguing for trying to do without any GUI toolkit at all. What is needed is an "appropriate-level" thin toolkit for X11 that balanges performance and programmer convenience better.

On the nature of bloat

Posted May 23, 2005 23:22 UTC (Mon) by njhurst (guest, #6022) [Link] (1 responses)

Well, except for the fact that except for emacs, those projects all have good, consistent guis. emacs only got a gui via other projects, and would never have got a gui at all otherwise. Trying to add a gui after the fact seems to result in poor interaction, commercial apps that have tried this invariably end up rewriting for a good gui.

I think arguing for a 'thin' gui is backwards. We want a 'thick' gui that encapsulates much of the interaction, and then convince people to spend some serious time optimising things. For example, the gtk tree view widget seems to spend a lot of time allocating and deallocating little blocks, if effort were put into optimising that then every app that used it would immediately improve.

On the nature of bloat

Posted May 24, 2005 2:40 UTC (Tue) by tjc (guest, #137) [Link]

We want a 'thick' gui that encapsulates much of the interaction, and then convince people to spend some serious time optimising things.

Who is "we?"

Speaking for myself, I would rather have a thinner GUI toolkit than what is commonly used nowdays, and let people make their own decisions as to its suitability for their particular needs.

I find it odd that it takes 10 seconds to start a web browser on my 3 GHz system with 1 Gb of RAM. If it took that long for a program to start 15 years ago, I would have thought that DOS had crashed...

On the nature of Mozilla's toolkit

Posted Jun 2, 2005 12:45 UTC (Thu) by markhb (guest, #1003) [Link]

If you look back at the start of the open-source Mozilla project, they didn't start with their own toolkit; they started with the original Navigator architecture of a common backend and various platform-specific front ends: one for Win32, one for Mac, one for Unix, each using it's native widget set (the original Unix versions used Motif, which meant that you had to have a Motif license to build the app in the early days). This had two problems:

The obvious Motif-related difficulty, and the fact that Lesstif was rudimentary at the time, and
The fact that most open-source developers were on Linux, while the most important platform from a user-acceptance perspective was (and is) Win32, which required Visual C++ to build.

Those, coupled with the fact that pulling out everything NSCP couldn't release had left the codebase unbuildable, led to a realization: since the difference in implementation between various platforms meant they essentially had to build widgets for HTML form controls, why couldn't they use those same widgets for the entire UI, cross-platform. That was the origin of Xptoolkit, and it was the coupling of that with the nglayout component (which became Gecko) that was the genesis of the original Mozilla 1.0 / Netscape 6.

On the nature of bloat

Posted May 23, 2005 10:17 UTC (Mon) by eru (subscriber, #2753) [Link]

One probably doesn't need to be an ASM expert to write a good word processor, but ditching the high level toolkit would probably be a step in the right direction.

If I recall correctly, many of the GUI apps for the early Macintoshes were written in Object Pascal, which is arguably a higher-level language than C. Assembly gurus are definitely not needed. Just good programmers.

On the nature of bloat

Posted May 23, 2005 2:41 UTC (Mon) by mmarq (guest, #2332) [Link]

" Totally irrelevant to my complaint! "

eh?!... if its not that the inovation in the Desktop point to 3D all arround then may be is irrelevant, but you're wrong because it isn't... but then why complein about X and GUI bloat as above ??

" It is what happends in the data structures and code behind the visible elements that is problem. Unnecessary window repaints "

You can't see properly the 3D acceleration hardware elements, specialy with the complexity involved in modern GPUs, then is nothing but to expect that code that touches 3D and even X subsystems trend more and more to be clumbsy and bloated.

" Yes, it is tolerable on >500Mhz >128Mb machines, but still often feels sluggish at times on 600Mhz (as does Gnome and KDE) "

??... belive one of your bigger problem is that you are in a dire need of a much powerfull machine, and apart but perhaps of more concern a much more powerfull GPU, not for mozilla but for more modern looking applications.

Overhead

Posted May 24, 2005 2:17 UTC (Tue) by tzafrir (subscriber, #11501) [Link]

And if I want to run 10 users on my system?

Do I really have to give 512MB per desktop? why isn't 64MB or even less enough?

Overhead

Posted May 24, 2005 8:48 UTC (Tue) by minichaz (guest, #630) [Link]

"a short sited [sic] 'hardware device driver policy'"

I'd love to know what this short sighted policy was. If it was not to encourage closed source drivers then that's not short sighted: it's sensible. The NVIDIA drivers are the only closed source software I use (firmware blobs excluded) and, in the past, they have caused more problems than anything else (though I hasten to add they are greatly improved these days).

"And even if there are drivers from the major vendors, Nvidia and ATI, they are not as good as the Windows counterpart"

That's just wrong. The NVIDIA drivers are built from a unified code tree so the core of Linux drivers is the same as the core of the Windows drivers. Unless there are serious issues I can't think of here I suspect the same is true for drivers released by any sensible company.

What the Linux Desktop Needs (OS Views)

Posted May 21, 2005 16:12 UTC (Sat) by b7j0c (guest, #27559) [Link] (5 responses)

>> Perhaps an IDL language in the form a XUL, that can speak a metatoolkit that will be the fundation of all futur toolkits

Thats probably as close as you can get - markup interpretation based on supported standards. Meaning the web.

ISVs have practically vanished as a class. In their place are websites and services. Ebay and Google are this generation's CA and Adobe. That is why anything that matters from this point forward is going to work in a web browser. No one cares about apps anymore beyond games and internet tools. And no, no one really cares about a word processor that is 1% better at this point - which is why many businesses are still using Office97. Productivity apps are in a no-growth market.

What the Linux Desktop Needs (OS Views)

Posted May 21, 2005 23:48 UTC (Sat) by mmarq (guest, #2332) [Link] (4 responses)

eh?!... the idea have nothing to do with commercial interests by itself. It has to do with the possibility of having the same "look & feel" across the board, whatever the application, no matter the disparate widgets & other toolkits involved, there may be a form of bring them together, with a *small & efficient" commom metatoolkit sharing the same theme engine,.. perhaps an IDL.

" Ebay and Google are this generation's CA and Adobe. That is why anything that matters from this point forward is going to work in a web browser. "

Even more so, because look & feel its not only fundamental for the desktop but for the development of applications also. There is a *killer feature* involved in having the possibility of consistent look & feel & behavor, no matter if your application is Network(includes the web) centered or not, and with only minor changes to the wrapping methods of the different languages that make a cross platform, be them C/C++, C#, D, Java, Python Pearl or Basic.

And Cross-Platform and toolkit and language development is a field where OSS excels. Pitty if it has to lose for a technical worst MS due to letargy and individualistic NIH sindromes.

I belive that Microsoft XAML is exactly that. It will function as a IDL for C#, Java#, Pearl#, VisualBasic# and possibily Python#, sharing the same *metatoolkit and theme engine* runtime implementation directive. Because even if i had 16Mbs ADSL it's stupid to wait for the browser to load all those program bits across the internet, when they can reside localy,

I belive that GUIs in itself as a paradigma, will always stay as a localy centered, sticked in front of the user, program layer.

What the Linux Desktop Needs (OS Views)

Posted May 22, 2005 2:53 UTC (Sun) by b7j0c (guest, #27559) [Link] (2 responses)

>> It has to do with the possibility of having the same "look & feel" across the board, whatever the application, no matter the disparate widgets & other toolkits involved

what if someone doesn't like your presentation? then they create an alternate model and you are back where you started.

face it, linux users clearly do not want one presentation layer to rule them all.

What the Linux Desktop Needs (OS Views)

Posted May 23, 2005 2:54 UTC (Mon) by mmarq (guest, #2332) [Link] (1 responses)

" face it, linux users clearly do not want one presentation layer to rule them all. "

That is the reason because there are *THEMES* and themes are extensibles, like one can see in KDE and less in Gnome... and even the theme engine can be extensible to some degree without losing consistent look&Feel...

What you're saying is like saying that everyone wants to be proudly alone in is small part of the desert, miles away from eachother, defending a couple of palm trees of their own oasis, like if there was a forrest everywhere that was a bad thing... its insane!

What the Linux Desktop Needs (OS Views)

Posted May 23, 2005 16:28 UTC (Mon) by b7j0c (guest, #27559) [Link]

>> What you're saying is like saying that everyone wants to be proudly alone in is small part of the desert, miles away from eachother

no, they just want to scratch thei own itches.

its not a corporation, its an ecosystem, not everyone wants to swim in the same direction.

What the Linux Desktop Needs (OS Views)

Posted May 23, 2005 3:36 UTC (Mon) by Arker (guest, #14205) [Link]

If you want a consistent look and feel (and I agree it's an advantage, although I don't think it's nearly as big as you seem to) you can do that. You can make a pure GNOME desktop, a pure KDE desktop, or if you really have taste you can use GNUStep instead.

What's that you say? All of these things are incomplete, they don't have everything you want?

Exactly. So either write the missing pieces you need, or deal with the inconsistencies.

Now if that consistent look and feel is such a killer feature, all you need to do is take one of those, fill in the missing bits, package it and sell your OS.

The reason people haven't done that is because no one with the resources to do it (and there are plenty of them in the business) really believes it's important enough to bother. If you're right and they're wrong, you've got a great opportunity to get rich proving it.

I think the original article misses a number of points, including the one above. It also keeps talking about Linux as a platform - which it isn't and never will be. Linux is a kernel. He's complaining about the practices of a number of OS vendors that use the linux kernel, but much of his complaining comes from the fact he seems to think they are all supposed to be selling the same OS. Complaining that Suse, RedHat, Debian, and Slack are different is like complaining that your Ford won't accept parts from an old Dodge. But they're all built on internal combustion engines!!! Give me a break.

The fact is he has a goal (a 'linux desktop platform' that caters to the needs of propriety software businesses) and is upset that everyone else doesn't support that goal. It's a senseless complaint. He has the freedom to pursue his goal, and even to use tons of pre-written code, including the kernel, the GNU tools, KDE, etc. produced by other people and given to him as a gift. But complaining that other people that don't share his goal aren't gifting him things written exactly to his specifications... senseless.

Article with an Agenda

Posted May 21, 2005 0:51 UTC (Sat) by huffd (guest, #10382) [Link] (1 responses)

This is another article about how wonderful it would be if this were a KDE world. Like the bleating of sheep, make your application run on my desktop. With statments like:
"Why can't we have a "KDE Desktop binding"? "

Here is the only sentence where the word Gnome is used and it has to do with being victorious over the "Gnome camp".
"And if we win the Gnome camp to support it via Freedesktop.org, it would guarantee that each and every application would run natively inside each desktop environment -- ISV products included."

I hope Microsoft buys TrollTech...

Article with an Agenda

Posted May 22, 2005 1:41 UTC (Sun) by sbergman27 (guest, #10767) [Link]

Sorry. I didn't read it like that at all. I'm a Gnome fan. I used to be a KDE fan. KDE 1.x had no equal. I stayed with it through about the time Keramik became standard (2.2? 3.0? I can't remember.) and then noticed that Gnome had gotten *really* good. So I've been solidly in the Gnome camp for some time and just don't see your complaint about the article.

The author is making a very reasonable, good, and true point that packaging for Linux apps is harder than packaging for an OS that doesn't have a zillion similar, but different, distros, and several similar, but different, "major" distros, many of which release new, improved and slightly incompatible versions every six months. And, of course, the existence of many Window Managers and a couple of different major Desktop Environments (any of which might be an option in any of the distro/version combinations). Add to that the fact that the community will jeer them if they cop out and standardize on, say, RedHat Enterprise Linux, and it's no wonder some companies decide it's too much work for too little gain.

That is what the author is saying. It's not a Desktop War issue.

Hey. Like The Force, the "Choice Is Good" argument that is so popular in the community has a "dark side" and this is it.

Binary Releases

Posted May 21, 2005 1:17 UTC (Sat) by shredwheat (guest, #4188) [Link]

I've installed many commercial applications that do not require the amount of multiple releases exampled in this article. I guess the drawback is that these binaries are not always integrated with the system package manager. But most of these are simple user installations.

Examples? Skype, Crossover, Doom3, Unreal Tournament, Teamspeak, Maya, Renderman...

The list goes on and on for otherwise closed applications that are not busy providing so many binaries. If it is too much trouble, try looking into the tools like Autopackage.org which are trying to support the environments of a single binary running on many distros.

Linux Desktop needs less commercialism

Posted May 21, 2005 1:36 UTC (Sat) by purslow (guest, #8716) [Link] (6 responses)

The man says:

"Look at the download site of NoMachine.com,
look closely on the list of NX Clients they offer ...
* there is exactly 1 MS Windows executable for download,
* while there are 16 (in words: sixteen) different packages for Linux".

Yes sir, please look really closely: 15/16 packages for Linux
are expressly for 3 commercial distros -- RH/Fedora, SUSE, Mandriva --
& only 1 is for a non-commercial distro, Debian.
Another leading non-com, Gentoo, has a package available in Portage,
which has been created by Gentoo's highly competent volunteer devs.

So the moral is: Linux distros put out by profit-making companies
are harming themselves by forcing software producers
to offer individual packages for all their many versions,
while the leading non-profit distros make life easy for everyone.

Linux Desktop needs less commercialism

Posted May 21, 2005 9:02 UTC (Sat) by micampe (guest, #4384) [Link] (3 responses)

So the moral is: Linux distros put out by profit-making companies are harming themselves by forcing software producers to offer individual packages for all their many versions, while the leading non-profit distros make life easy for everyone.

Oh yes... Red Hat 6.2 and SuSE 6.4 are supported (more than five years ago, IIRC). Just try installing that on Potato or whatever came before it...

Potato....

Posted May 22, 2005 15:55 UTC (Sun) by kmself (guest, #11565) [Link] (2 responses)

Red Hat 6.2 and SuSE 6.4 are supported (more than five years ago, IIRC). Just try installing that on Potato or whatever came before it...

Point is that Debian does (and has) offered a transparent upgrade process, while RH and SuSE tend to require a wipe-and-rebuild update. Which is sold as a commercial product. Just ask those who were bit by the 7.x / 8.x / 9.x upgrade / EOL switcheroo. RH burned through a hell of a lot of goodwill with that. Yes, it addresses their (current) business need, but ...

While it's quite possible that there are folks still stuck on RH 6.2 (and I've seen recent postings on both support and job boards suggesting just that), it's vastly easier for a Debian-based distro to be kept constantly current.

The real point here is that both NoMachine and Red Hat are running into the problem that proprietary interests, at least as dictated by their chosen business model, are not aligned with good software practices. My perspective is Debian (others will point to Gentoo, Slackware, or the BSDs which function similarly), and it's interesting how ~1000 part-time volunteers manage to provide some 18,900+ packages, when a company with dedicated staff can't keep a handful of distros straight.

I'd say it's time for NoMachine (and other ISVs) to learn to use the synergy rather than fight it.

--
Karsten M. Self linuxmafia.com/~karsten/

Potato....

Posted May 22, 2005 20:31 UTC (Sun) by riddochc (guest, #43) [Link]

I don't know about RedHat, but in defense of SuSE, my main desktop and laptop were installed with 9.0, upgraded to 9.1, and again to 9.2. I'm about to upgrade to 9.3 in a few hours here, and I'm not expecting problems.

I've yet to have a SuSE upgrade fail (knock on wood).

There's no need for a "wipe and rebuild update" with SuSE. Your examples mainly mention RedHat, please clean that brush before painting SuSE with it.

Potato....

Posted May 23, 2005 1:37 UTC (Mon) by bojan (subscriber, #14302) [Link]

> Point is that Debian does (and has) offered a transparent upgrade process, while RH and SuSE tend to require a wipe-and-rebuild update.

My main desktop at home started off as a Red Hat Linux 5.0 machine. Then it went to 5.1, 5.2, 6.0, 6.2, 7.2, 7.3, 9, FC1, FC2 and FC3, all with the upgrade options. Hardware has been changed a few times as well - I even flicked between ext2/ReiserFS/ext3 (cp -xa works great :-). Yes, when packages get upgraded to an incompatible version (in terms of configuration directives), you usually have to adjust you configuration to the new format (e.g. Apache 1.3 to Apache 2.0), but in general things work OK.

Soon, it will be FC4 and I'm not expecting to wipe any data off the machine before doing so. Sure, everything's always backed up, but that a different cattle of fish.

Linux Desktop needs less commercialism

Posted May 24, 2005 12:12 UTC (Tue) by ranger (guest, #6415) [Link] (1 responses)

Yes sir, please look really closely: 15/16 packages for Linux are expressly for 3 commercial distros -- RH/Fedora, SUSE, Mandriva -- & only 1 is for a non-commercial distro, Debian.

Seems you're confusing commercial with Free ...

Another leading non-com, Gentoo, has a package available in Portage, which has been created by Gentoo's highly competent volunteer devs.

Well, at the time those distributions were released, NX was not GPL.

At present, NX is in Mandriva 2005LE, the commercial distribution that also has a few highly competent volunteer devs (one of whom packaged NX).

But, your argument is irrelevant for proprietary software ... especially the kind Gentoo may not distribute in distfiles ...

Unless of course you were recommending that everyone should statically link binaries (as Gentoo users would have had to do before NX was GPL'd), or implyng that the "highly competent volunteer devs" from Gentoo wrote the GPL version of NX from scratch?

Linux Desktop needs less commercialism

Posted Jun 3, 2005 15:08 UTC (Fri) by zakaelri (guest, #17928) [Link]

What the Gentoo devs do for proprietary packages is write an encapsulating ebuild, not rewrite the application itself.

Portage determines dependencies, & installs them. After that, they use the original installer to place the files in a "sandbox". At this point, they can swap in their own platform specific config files and do whatever else they need to prep the install. Then they merge the sandbox with the current filesystem.

They provide ebuilds for several proprietary apps (particularly games), and they all work this way. To name a few: sun-java, blackdown, ut2k4, point2play, & neverwinter nights (along with wine-nwn).

Business opportunity

Posted May 21, 2005 4:52 UTC (Sat) by ncm (guest, #165) [Link]

Looks like a business opportunity to me. Installer vendor says, "build to this environment (2.4.8 kernel, say), and static-link; we'll do the rest."

Why should volunteers have to help proprietary companies sponge off their efforts? The corps can pay for the service, just as they pay Installshield to get things to install on a hundred radically different W32 targets. The lack of a standard Java environment has saved us untold agony trying to get supposedly portable Java programs actually to run and not use up all of swap.

What the Linux Desktop Needs (OS Views)

Posted May 21, 2005 5:38 UTC (Sat) by hmmm (guest, #28931) [Link] (2 responses)

Whiners!

If you want your commercial software to run on and be included with all Linux distrobutions by default then open source it.

If you want to keep the source closed then release a staticly compiled binary version of it.

If you want to integrate it into a distro then do it, release your software targetted for specific distributions and maintain your own mess. You chose this path, nobody twisted your arm to make things this difficult for you. Suck it up. Bitch.

http://www.blender3d.org/cms/Blender.31.0.html

Notice these professional have no problem supporting all Linux distros with binary releases. If you do, you suck.

This is what the Linux Desktop does NOT Need

Posted May 21, 2005 13:41 UTC (Sat) by sdalley (subscriber, #18550) [Link] (1 responses)

You are a guest here. It behoves guests to play by the house rules of "polite, respectful, and informative", as the rest of us try to do. Subscribers do not enjoy paying for the privilege of reading abuse that can be had for free any day on slashdot.

Regarding your points, you will note that NoMachine.com *already* release product for 15 different Linux dists. Is this possible? Of course. Does it create support and maintenance headaches? Again, of course. Is it off-putting for new entrants? Again, of course.

We make Linux better by quietly improving the tools and the infrastructure, not by ranting and raving at vendors who are doing just that, and scaring off others who might otherwise seriously consider it.

This is what the Linux Desktop does NOT Need

Posted May 22, 2005 2:46 UTC (Sun) by hmmm (guest, #28931) [Link]

You're right, that was a bit rude. I'll try to keep that kinda rage for osnews.

However. Should we do everything in our power to cater to proprietary software dealers?

How much time or money should we spend out of our own pocket to do it?

Unnecessary synchronous stability in a distributed development model can cost a lot of time and possibly slow the rate of progress, if nothing else.

Maybe they should pay for stability.

The customer, for the privelege of running a stable OS like RHEL or SuSE with support for commercial apps, is the one who is paying today.

But I think once there are enough people using it, once there is a market for commercial software on it, the apps will be happily ported over. They just want sales in very large numbers. They follow the carrot.

If Apple released OSX for the PC I bet most PC games would be ported in no time. The market would explode for OSX software on X86, so many people would be running it. The same thing will happen for Linux when its ready.

But it isn't ready, just yet. And if the vendors aren't prepared when it is ready they will have to spend the money to catch up. Not our problem.

The point is everyone gets equal opportunity to be part of the Linux Desktop. Nobody gets special treatment. Secret closed-door meetings to put an AOL icon on your desktop will not be tolerated here. Competition is fierce. Either keep up or quit.

A lot of whining, little substance

Posted May 21, 2005 11:36 UTC (Sat) by bojan (subscriber, #14302) [Link] (19 responses)

When I started reading the article, I got the impression that there's going to be some really nice point about binary compatibility and the like. But, no luck.

I'm not sure why the author is so pissed off with various RPM builds. When I look at Dag's repository (http://dag.wieers.com/home-made/apt/), it appears that he alone builds 37,922 RPMS for 2,146 different projects, spanning Red Hat Enterprise Linux (2.1, 3 and 4), Fedora Core (1, 2, and 3) and Red Hat Linux (6.2, 7.3, 8.0 and 9), for i386 and x86_64. If he can pull this off, all by his lonesome, a company should have no problems doing a few. No? Especially given the fact that many are simple recompiles obtained by rpmbuild --rebuild.

It's just a matter of time before we see more unification in terms of binary compatibility and packaging. Linux as a consumer, even enterprise desktop is a relatively new thing. Things will get simpler in time, but they are not too bad even now.

A lot of whining, little substance

Posted May 21, 2005 16:16 UTC (Sat) by b7j0c (guest, #27559) [Link] (8 responses)

>> It's just a matter of time before we see more unification in terms of binary compatibility and packaging.

I doubt it, this is in fact getting worse every day with more distros rolling their own package formats and tools. Autopackage? Sure. Who uses it? No one.

The previous posters were correct. If you want your app available for a linux distro, open source it and it will magically appear in repositories. Keep it closed source and you are on your own.

A lot of whining, little substance

Posted May 22, 2005 6:03 UTC (Sun) by bojan (subscriber, #14302) [Link] (4 responses)

> I doubt it, this is in fact getting worse every day with more distros rolling their own package formats and tools. Autopackage? Sure. Who uses it? No one.

This is your point of view and I respect it. But, there is always a handful of "major" distros, with a handful of major packaging formats to support. Cutting an RPM spec file is not all the different for various RPM based distros - most times the file can be directly reused. This means that all that is required is a rebuild - a completely automated process. I doubt that proprietary software vendors would trouble themselves with supporting non-mainstream Linux distros. They live and die by the number of licences sold, so they won't see them as important at all.

> The previous posters were correct. If you want your app available for a linux distro, open source it and it will magically appear in repositories. Keep it closed source and you are on your own.

In general, I agree. However, this boils down to the old argument: which is more important - freedom or popularity. If we're talking about freedom (RMS argument) there is no place for proprietary software, so we must be talking about popularity. In other words, if Linux on the desktop is to be popular, it has to be a good platform even for proprietary software vendors (that's the argument made by the original article). So, we have to pick - do we need those proprietary software vendors to supply software for the Linux desktop, or are we confident enough that we'll do fine with open source tools alone.

From my personal experience, I know that it would be really hard (read: impossible) for me to use my Fedora Core box at work if I didn't have access to Flash, Java, Cisco VPN and a whole bunch of other proprietary software for various management tasks on that platform. As it stands, I can get all of these for Linux - therefore my desktop is FC. Otherwise, I'd have to use Windows.

In an ideal world, Macromedia would open source Flash, Sun would open source Java and Cisco would give open source downloads of their VPN client. But the fact (at the moment) is that they don't. I'm sure some people prefer to wait, while others prefer to make the platform proprietary software "friendly".

My beef with the article is that the arguments in it aren't that strong. I've build RPM packages (in my spare time, no less) and I can testify it isn't hard. I also see others doing it in large numbers, so it can't be hard even if I were some kind of of RPM guru (I assure you, no such luck :-).

Another interesting example for me is JPackage (http://www.jpackage.org/), which provides over 1,500 Java related RPMS. I they (some 20 people) can do it, why does the author of the article see such problems with the process?

A lot of whining, little substance

Posted May 22, 2005 16:32 UTC (Sun) by b7j0c (guest, #27559) [Link] (3 responses)

>> Cutting an RPM spec file is not all the different for various RPM based distros - most times the file can be directly reused.

This is false. Creating an RPM is a reusable process, but the resulting file is not portable between RPM supporting distros. Rarely are they portable even between versions of the same distro.

A lot of whining, little substance

Posted May 22, 2005 22:00 UTC (Sun) by bojan (subscriber, #14302) [Link] (2 responses)

> This is false. Creating an RPM is a reusable process, but the resulting file is not portable between RPM supporting distros. Rarely are they portable even between versions of the same distro.

I was talking about creating a SPEC file (which is a text file - a script of sorts). One gets binary (and source) RPMS as a result of running a build process against that script. Most spec files (and this is where the work goes) ARE portable between different distros and different versions of the distro.

Don't confuse the RPM with its spec file.

A lot of whining, little substance

Posted May 23, 2005 16:31 UTC (Mon) by b7j0c (guest, #27559) [Link] (1 responses)

>> I was talking about creating a SPEC file

and what does that buy you? .tgz's are also portable between distros. your argument comes down to nothing more than compiling from source.

A lot of whining, little substance

Posted May 23, 2005 20:01 UTC (Mon) by bojan (subscriber, #14302) [Link]

The author of the article was whining about great difficulties for ISVs (i.e. peopel with the source for their proprietary software) to support more than one RPM based distro. This is nonsense - all the work goes into creating a single spec file, after which you run rpmbuild against it, which then creates the binary and source RPMs, signs them and finds majority of the dependencies automatically (i.e. you don't have to hard code them at all). If one is clever, the same file can create package versions automatically depending on the distro. All one needs to do is upload them to the web server.

I don't see why that is so hard. And it gets better - there are gazillion SPEC files floating around. Heck, Fedora Extras even has an RPM that creates a template SPEC file according to the Extras guidelines. I would think that ISVs willing to play in the Linux market would be aware of such things...

A lot of whining, little substance

Posted May 22, 2005 23:48 UTC (Sun) by njhurst (guest, #6022) [Link]

Inkscape uses autopackage.

A lot of whining, little substance

Posted May 23, 2005 13:33 UTC (Mon) by jedidiah (guest, #20319) [Link]

Pure Caca.

Commercial developers now have no ability to fully rely on any built-in OS package management. This applies to All Unixes as well as WinDOS. ANY system is going to present the problem of an infinite combination of OS releases and patch updates.

Some vendors even provide special tools to deal with this.

vmware will rebuild it's own kernel modules.

oracle has a relink utility.

And even Java won't insulate you from platform specific quirks.

Anyone trying to make this into a Linux only issue just isn't being honest.

A lot of whining, little substance

Posted May 24, 2005 2:34 UTC (Tue) by tzafrir (subscriber, #11501) [Link]

Not exactly. You could still allow volunteers to help, assuming you allow free download (e.g: skype, acrobat reader?)

Binary incompatibility issues indeed require a rebuild. No way around this. But the vendor only needs to release a set of binaries for all platforms.

Volunteers can later package them in e.g. RPMs for their specific distros.
Thisngs like menu files, cron files, location of documentation directory, dependencies and whatever.

A lot of whining, little substance

Posted May 22, 2005 0:09 UTC (Sun) by mmarq (guest, #2332) [Link] (3 responses)

Is going to hit an halt. If he managed an incredebly 10 different packages a day, compiling and debugging if need, he has done nothing else arround the clock, forgotting to sleep inclusive, in the last 10 years. Do the math 37,922/10 for the number of days and nºdays/365 for the number of years. There is something fishy about those numbers.

Even if a Guiness record, due to incrising complexity and size of programs, and therefor RPMs, he's certainly going to stop before he's going insane.

A lot of whining, little substance

Posted May 22, 2005 5:33 UTC (Sun) by bojan (subscriber, #14302) [Link] (2 responses)

Actually, he is a very clever guy (and he does have others helping - I exaggrated a bit in my original post :-). But there is nothing fishy about the numbers at all, because he built a build harness that makes building all those packages a breeze. If you don't believe the numbers, simply visit this page:

http://dag.wieers.com/home-made/apt/packages.php

And have wget (or whatever tool you like) at it to download every single package. Then count them.

But my point is something else. Building packages with RPM (especially once you get the hang of it) is really easy. For instance, once Fedora Core 4 hits release, Dag will simply run his build process again, therefore generating majority of packages for FC4. There are a few that are bound to break, so he'll adjust the harness and move on.

There is another point to be had here. If proprietary software vendors wish to build their software more easily, I'm sure Dag and others are more than willing to help them with that. For a fee, of course...

A lot of whining, little substance

Posted May 23, 2005 3:13 UTC (Mon) by mmarq (guest, #2332) [Link] (1 responses)

" But there is nothing fishy about the numbers at all... "

That way of course not ! He appears to be making RPMS for RED HAT centered stuff only. If he had to support the most popular 50% part of the more than 100 Distros out there than he's brain had already exploded long time ago.

A lot of whining, little substance

Posted May 23, 2005 10:28 UTC (Mon) by bojan (subscriber, #14302) [Link]

Yes, for sure. But neither he nor proprietary software vendors have to do that (i.e. they don't care about something that commands very little market, if any). They only need to support a handful of RPM based distros, for which they can usually have a SINGLE spec file which will build against any of these distros.

Bottom line, the author of the article is greatly exaggerating the difficulty of supporting more than one distro.

It's the testing, not the package building

Posted May 23, 2005 14:10 UTC (Mon) by wilck (guest, #29844) [Link] (5 responses)

The complaints are not about packaging.

For commercial software vendors, building the RPM is only a small part of the story. How extensively does Dag test each-and-every package he builds? Does he provide any warranties or support?

Testing, quality assurance, and formal release procedures are an essential part of the workflow in every software company. These steps must be done for every package that is provided, and they take many times the time and money than the packaging process itself (which, in all probability, is done automatically).

It's the testing, not the package building

Posted May 23, 2005 20:06 UTC (Mon) by bojan (subscriber, #14302) [Link] (4 responses)

You mean like testing against Windows 95/98/Me, NT 4.0 Wks, NT 4.0 Server, 2000 Pro, 2000 Server, 2003 Server, XP Pro, XP Home, 2003 Server 64-bit (Itanic and x86-64) and XP 64-bit (Itanic and x86-64)?

It's the testing, not the package building

Posted May 24, 2005 7:29 UTC (Tue) by wilck (guest, #29844) [Link] (3 responses)

If you focus on OSes no more than 5 years old, it boils down to 2000, 2000 Server, XP, 2003 Server. 5 products.

In the same time frame, you get at least RedHat 8.0, 9, FC1, FC2, FC3, RedHat Enterprise 2.1, 3.0, 4.0, SuSE 8.1, 8.2, 9.0, 9.1, 9.2, 9.3 and Enterprise Server 8 and 9, Debian potato, woody (and probybly sarge), plus numerous distributions from Mandrake, Conectiva, Ubuntu, Gentoo, you name it. Making matters worse, Linux distributors put less efforts in binary compatibility between "Service packs" (Novell/SuSE) or "Quaterly updates" so if you're out of luck, you need to do extensive regression tests against those as well (absolutely necessary if your software has kernel components).

That's already 4 times the number of Windows flavors, for a substantially lower market share of Linux vs. Windows (taking the point of view of a manager in an ISV company, which I am not).

If you really want to count x86_64/ia64 distributions separately, multiply the above list accordingly.

Do you get the picture?

It's the testing, not the package building

Posted May 24, 2005 9:53 UTC (Tue) by bojan (subscriber, #14302) [Link] (2 responses)

> RedHat 8.0, 9, FC1, FC2, FC3, RedHat Enterprise 2.1, 3.0, 4.0

I'll just focus on RH stuff, because that's what I'm familiar with. Why would someone provide binary builds for products that are out of support, such as 8.0, 9, FC1 and FC2? If they are doing that, they are simply asking for trouble. So, in RH world, it is really two current versions of Fedora and all Enterprise versions. Otherwise, you may as well count all Windows stuff, like I did.

> Making matters worse, Linux distributors put less efforts in binary compatibility between "Service packs" (Novell/SuSE) or "Quaterly updates" so if you're out of luck, you need to do extensive regression tests against those as well (absolutely necessary if your software has kernel components).

Not true. Supported Linux distros, such as Red Hat Enterprise Linux, make certain guarantees in respect to binary compatibility. Not that I haven't seen NT machines broken by a service pack...

It's the testing, not the package building

Posted May 24, 2005 12:08 UTC (Tue) by wilck (guest, #29844) [Link] (1 responses)

So, in RH world, it is really two current versions of Fedora and all Enterprise versions.

Well, OK. That's 5 distros for RedHat alone, same number as for the complete Windows world. For SuSE/Novell it's 9.0, 9.1, 9.2, 9.3, SLES8, SLES9. That's 11. Now for Debian/Mandrake/Ubuntu/Gentoo/Mepis/Whatever. You'll arrive at 20 at least.

Your argument about NT is correct, of course. But Software vendors that need to give guarantees need to be very confident about Red Hat's "certain guarantees" to rely on them with no testing on their own part. Look at SAP, for example. They are certainly not clueless wrt linux, and they make separate releases for errata kernels. I bet they have reasons to do so.

Please understand that I'm not arguing against Linux. I am just trying to explain why third party vendors have problems supporting the many different Linux flavors - because "supporting" means more than building an .rpm package.

Supporting Linux currently costs more resources for an ISV than supporting Windows. This is hard to dispute. To reduce the efforts, an ISV can decide to focus on a few very stable distros: RedHat and Novell enterprise probably, and Debian stable. That, however, would leave most of the community with their favorite distributions unsupported, and that's probably not what you and I want.

It's the testing, not the package building

Posted May 24, 2005 21:21 UTC (Tue) by bojan (subscriber, #14302) [Link]

> Look at SAP, for example. They are certainly not clueless wrt linux, and they make separate releases for errata kernels. I bet they have reasons to do so.

I have no idea why SAP have chosen this way of doing things, but there are plenty others that didn't: Oracle, NVidia, Cisco, Macromedia - they all ship just one version of their proprietary products that work across MOST Red Hat flavours, including weird things like latest development Fedoras. So, maybe SAP aren't as good as they'd like to think they are.

I understand where you're coming from with your arguments, just like many other posters. It does come down to being competent as an ISV and not doing things that you aren't supposed to be doing, especially in the kernel space (where most breakage appears to happen). But, I'll repeat my main point again: the author of the article greatly exaggerates the difficulty of doing this. The number of products and RPMS alone doesn't necessarily mean much. I agree that supporting means doing more than just building RPMS, but there is always a few (very similar) flavours that have close to 90% of the market - the rest is just noise from proprietary vendors' point of view. Whether that leaves me or you without that proprietary software is something they usually don't concern themselves with, if the numbers are small enough.

More pointless gibberish

Posted May 21, 2005 16:02 UTC (Sat) by b7j0c (guest, #27559) [Link] (2 responses)

As long as desktop computing "matters", the breakdown of the market is not going to change dramatically from what you see today. Apple has a better product but still can't move their marketshare much. The desktop market is over. Its what is next that you should be concerned about. Game consoles, cell phones, home media appliances.

Any of these devices will provide internet application support (web, mail, IM, chat) in a few years as well as their primary function (games, movies, etc) and that is all users really want. And no Aunt Tilly doesn't spend most of her time on the computer entering recipes in a word processor followed by occasional spreadsheet use. That is the 1992 vision of computing. Do you even see Microsoft making strong efforts to sell Office to home users? There's no market there.

I'm all for improving the linux desktops - but to be certain it is simply a matter of improving what the existing target audience wants. Anyone who wants dead-simple, it-just-works computing already uses a Mac. Anyone who wants to be part-of-the-majority already runs Windows.

More pointless gibberish

Posted May 22, 2005 6:34 UTC (Sun) by bojan (subscriber, #14302) [Link] (1 responses)

> The desktop market is over.

That's really pessimistic. It sounds almost as if we shouldn't even be trying, because others have captured the market and that's the end of it. No more competition - ever. I certainly hope that isn't true.

> Anyone who wants dead-simple, it-just-works computing already uses a Mac.

I'm not sure where all this "Mac: the ultimate desktop" is coming from, but it may as well be an urban legend as far as I'm concerned. I have a Mac (or better - I purchased one for my daugther) and it's neither always dead simple nor does everyting just work. In fact, it has major dramas setting up printing to a Linux CUPS server (while running CUPS itself), programs occasionally crash, UI is not that it's cranked up to be (some design choices boggle the mind). Sure, eye candy is great, but the platform is not without faults.

More pointless gibberish

Posted May 22, 2005 16:34 UTC (Sun) by b7j0c (guest, #27559) [Link]

>> That's really pessimistic. It sounds almost as if we shouldn't even be trying

No, just don't have any expectations other than making a product *you* prefer more than the other available options.

What the Linux Desktop Needs (OS Views)

Posted May 22, 2005 3:12 UTC (Sun) by neoprene (guest, #8520) [Link] (1 responses)

"...any commercial software vendor pondering to sell his product or service on the Linux platform is horrified by the complications he has to deal with."

Monoculture is nice for launching a commerical app, but not even MS sports totally equal OS's, version differences exist. These differences are not that big a challenge as to prevent apps from being made for win95,98,me,nt,2k,xp etc.

As Linux adoption grows the commercial players will crank out their calculators and find out that its not to hard to make adoptions for different Linux packaging systems, or even .bin files like Sun Java, Doom3 etc.

I hope the vendors horrification will be exceeded by their profits after ignoring weenie pundits.

What the Linux Desktop Needs (OS Views)

Posted May 22, 2005 6:23 UTC (Sun) by bojan (subscriber, #14302) [Link]

> Monoculture is nice for launching a commerical app, but not even MS sports totally equal OS's, version differences exist.

In fact, another big change is about to hit all Windows ISVs - WinXP 64-bit edition (for x86-64) doesn't run 16-bit software at all. MANY installers, even many programs are still 16-bit, so whoever wants to play on the new 64-bit version will have to provide at least a 32-bit version of installer and software.

What the Linux Desktop Needs (OS Views)

Posted May 22, 2005 13:19 UTC (Sun) by tialaramex (subscriber, #21167) [Link] (2 responses)

Having examined some of the available packages I conclude that it could just as easily have been two or three different Windows packages (one each for Win95, Win NT4, and one or two for the rest) and three or four Linux packages (say one for Debian, one for older RPM-based distros and one for more recent RPM distros, plus optionally a binary installer)

Obviously someone felt that it would be better to have just one Windows package, even if sometimes that meant making decisions that the NXclient wouldn't work as well as it could on Windows XP.

Meanwhile someone (else?) decided that Linux users would want binaries recompiled for every possible version, just in case it makes a difference. So although the FC1 binaries will run on FC3, they provide separate binaries and separate packages.

The fact that these conflicting approaches happened in the same project says nothing whatsoever about "What the Linux Desktop needs"... The Linux downloads for NX are tiny when compared to the Windows download, because they don't have to bundle everything that was thought of between 1995 and today, for some people that's going to be an advantage, and if those people choose NX on Linux that more than out-weighs the small cost of running rpmbuild an extra dozen times.

(Because yes, literally the difference between these packages is typically the same build script run on a machine with a different distro. RPM obeys the rule from Joel on Software, among others, that says a complete build must be just one button push, no supervision or interaction needed)

Static compilation

Posted May 22, 2005 21:30 UTC (Sun) by man_ls (guest, #15091) [Link] (1 responses)

The Linux downloads for NX are tiny when compared to the Windows download, because they don't have to bundle everything that was thought of between 1995 and today,

The win32 download is 3.87 MB, while the distro-specific downloads are about 1 MB. But there are also statically compiled versions, which range from 3.2 to 3.6 MB. By the way, the .deb package is 3.3 MB. Are you sure that the difference is not about bundling glibc?

Static compilation

Posted May 22, 2005 22:04 UTC (Sun) by kobserver (guest, #30087) [Link]

I can tell you why the Win32 download of NX is larger than a typical Linux package download:

* NX clients always need an X server to display the remote session
* Linux typically have an X server installed and NX clients use that
* Windows typically dont have an X server installed so the NX Win32 client installtion package includes a complete X server for Windows

(The Win32 package currently uses the Cygwin XFree86 X server, and therefore also includes the cygwin.dll)