Re: [RFC] Unify KVM kernel-space and user-space code into a singleproject

From: Avi Kivity
Date: Mon Mar 22 2010 - 13:31:01 EST


On 03/22/2010 04:26 PM, Ingo Molnar wrote:
* Avi Kivity<avi@xxxxxxxxxx> wrote:

On 03/22/2010 01:39 PM, Ingo Molnar wrote:
Reality is, the server space never was and never will be self-sustaining
in the long run (as Novell has found it out with Netware), it is the
desktop that dictates future markets. This is why i find your views about
this naive and shortsighted.
Yet Linux is gaining ground in the server and embedded space while
struggling on the desktop. [...]
Frankly, Linux is mainly growing in the server space due to:

1) the server space is technically much simpler than the desktop space. It
is far easier to code up a server performance feature than to make
struggle through stupid (server-motivated) package boundaries and get
something done on the desktop. It is far easier to code up a server app
as that space is well standardized and servers tend to be compartmented.
Integration between server apps is much less common than integration
between desktop apps, hence the harm that our modularization idiocies
cause less harm.

2) Linux's growth is still feeding on the remains of the destruction of Unix.

Agreed (minus the 'package boundaries' stuff). Also, Linux is cheaper than Windows.

Linux is struggling on the desktop due to the desktop's inherent complexity,
due to the lack of the Unix inertia and due to incompetence, insensitivity,
intellectual arrogance and shortsightedness of server-centric thinking, like
your arguments/position displayed in this very thread.

It's struggling because it isn't competitive technically with other desktops, because there is no application base, because of a chicken-and-egg problem with some drivers, because lack of a stable ABI means you can't get a driver CD with your device so you need a yet-unreleased kernel, because the zillion binary incompatible distributions mean that application developers don't know what to code and test for, because of lack of documentation, to name a few. At least it's improving all the time.

The incompetence, insensitivity, intellectual arrogance and shortsightedness of server-centric thinking of my arguments/position are a result of this, not the cause.

[...] Apple is gaining ground on the desktop but is invisible on the server
side (despite having a nice product - Xserve).
But the thing is, Apple doesnt really care about the server space, yet. It is
lucrative but it is a side-show: it will fall automatically to the 'winner' of
the desktop (or gadget) of tomorrow.

It won't automatically fall to Apple, there's tons of middleware and server apps that need porting (the "ecosystem"), plus they need to work hard on improving their kernel which is desktop oriented. Looks like they're interesting in other things.

Has the quick fall of Banyan Vines or Netware (both excellent all-around
server products) taught you nothing?

Not familiar with Banyan, but wasn't Netware a cooperative multitasking command line only thing? It couldn't compete with preemptive modern system with a nice GUI. Windows didn't need the desktop to win that fight.

We need a lot more desktop focus in the kernel community. The best method to
achieve this, that i know of currently, is to simply have kernel developers
think outside the kernel box and to have them do bits of user-space coding as
well - and in particular desktop coding. To eat our own dogfood in essence.
Suffer through crap we cause to user-space. To face the _real_ difficulties of
users. We seem to have forgotten our roots.

Try it yourself and report the experience. Note: perf is not desktop development, it's kernel tooling development.

[...]

It's true Windows achieved server dominance through it's desktop power, but
I don't think that's what keeping them there now.
What is keeping them there is precisely that.

Not at all. They have excellent development tools and lots of middleware and other third party products that make it easy to pick Windows. For example, Exchange is more or less standard for groupware, and they made C# and the technology around it easy to develop for, learning from Java's mistakes.

In any case, I'm not going to write a kvm GUI. It doesn't match my skills,
interest, or my employer's interest. If you wish to see a kvm GUI you have
to write one yourself or convince someone to write it (perhaps convince Red
Hat to fund such an effort beyond virt-manager).
As a maintainer you certainly dont have to write a single line of code, if you
dont want to. You 'just' need to care about the big picture and encourage/help
the flow and balance of the whole project.

I haven't written that line of code, and no one else has either. Don't tell me they're all scared of me.

--
error compiling committee.c: too many arguments to function

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/