> Date: Thu, 26 Aug 2010 07:42:30 +0000
> From: <email address hidden>
> To: <email address hidden>
> Subject: Re: [Bug 1] Re: Microsoft has a majority market share
> 
> On Wed, Aug 25, 2010 at 23:46, Faldegast <email address hidden> wrote:
> > This is where Apple got it right. They dont make OS X work with all
> > hardware. They say "this is how Mac hardware works" and then they let
> > everyone that complies get to be called "Mac hardware".
> 
> I tend to agree with you. And even because people rather choose to put
> Ubuntu on their new machine than reinstalling their old pot where the
> HD died, so putting more focus on new users on new machines would not
> be the worst IMHO. That said, I would like to see continued efforts to
> make Linux run on other hardware too. Don't forget, that especially
> the strength of Linux to run on any hardware brought Linux to be run
> on Routers and even Phones too. So the efforts to support all kind of
> different hardware should not be stopped.

Yes. We should strive to have as much hardware as possible. But still without valuable time and money to support vendors that ignore us. Linux/Android phones with official Linux drivers and documentation should be supported, and so should Linux routers. However in cases where there is a lack of supported hardware I think we should work on it within the community. Router corporation does not support Linux? Then we should build our own routers with components that is certified for Linux. There are quite many of us that want such a thing so we should be able to finance it. For example i stumbled across the Armadeus embedded Linux board a while ago.

Another thing I have been thinking about is an Open Stock Market (based on OSS of course) which could make it simple to start and invest in new FOSS companies. Classic stock markets is not user friendly and its hard for the average user to get involved. Such a stock market should be Web-based and use payment methods such as paypal making it easy to buy and sell stocks. However, now I think I'm gliding of topic... :)

I agree that we should continue efforts to support all KINDS of hardware. However we do not really require more then one component of each kind. If we have one phone of every kind of phones that is sufficient. More does not hurt but we should not stretch our resources thin trying to support everything.

> 
> So it should be that way:
>  
> Q) Will my printer work with Linux?
> A) Is it certified? - Then for sure, if not, perhaps.
> 
> This would bring confusion only for those buying non-certified
> hardware, but offer more than Apple does.
> 
> 
> > Windows has a layer above COM for this that is called ActiveX,
> > and is used extensively to share graphic component. Obviously ActiveX is
> > far from perfect because the new .NET assemblies are not fully
> > compatible with COM/ActiveX. I do not really know why, but we should
> > analyze this so we do not design something with similar flaws.
> 
> Fully agree with the COM/ActiveX argument - I am a system integrator
> and now developing OS independent with Java, I miss the COM - I would
> like to have - not just a Linux-bound COM-alternative. I would like to
> see an OS independent way of reusing components and GUI elements. -
> Think that Web-Services basically are just a workaround for the lack
> of having such interfaces. The java related RCPs approaching a
> solution were only for Java world, but we need an OS agnostic and
> language agnostic solution. This is the only way to achieve widely
> adoption.
Yeah. Perhaps I use "Linux" and "Ununtu" to much when i really mean "FOSS". I agree that it should not be Linux specific, what i meant was that Linux needs something like this but the need is as great in other operating systems, including Windows. I am a firm believer that application development should be OS-agnostic, so we should have a framework that works everywhere.
Web Services have developed into something really good and fast for remote OOP, once protocols liberated from XML appeared. "Binary XML" like Fast Infoset is currently the best solution for remoting. I have studied this a lot and that's my conclusion. There is currently not a FOSS C implementation of Fast Infoset, but that's just an issue of creating one.



I think its a bit amusing that Web Services that was supposed to be XML 
and easy to read is developing into a fast binary protocol like RPC. In 
the end speed does matter.

However as i stated before we also need something for local IPC, running Fast Infoset over localhost will not be able to compete with shared memory solutions. We probably meed a solution similar to shared memory but with more kernel-enforced security. Something where we can allocate a memory "object" and pass it around. With shared memory all applications passing an object around must have access to all shared objects which honestly is a complete mess.

There are some API:s that are able to do no-copy communication that works similar to this. Perhaps extending the sockets architecture so that we can do no-copy localhost communication will actually allow us to use web services even for local communication at shared memory speed. However we would have to extend the Web Service API to store such an object rather then just transfer it, so we can have a no-copy architecture. If we can do something aligned to the existing Web Service API then we could save a lot of time, and as WS has become the de facto API for remoting it is easy to convince others to use it locally. Many already do use WS localy and if we can remove the performance penalty then i think the discussion will be sort.

I think we really need the input from some kernel hacker here. 

 
> At the moment I cannot develop for Linux only, because for companies
> there is a transition going over many years until all used
> applications run also on Linux. This cannot be changed from one day to
> the other. What applies much for companies often partly applies for
> private persons or small businesses (often either being
> one-man-shows).

I agree to that. We need OS-agnostic API:s. That's why Web Services is so popular in remoting. Even when using slow XML it still was a platform-agnostic format. Creating good local IPC may require some kernel hacking, but as long as it can be adopted by all mayor operating systems its worth it. It make take time to establish something that requires kernel-level support, but its better then not having a good local IPC solution.

I dont really care how the API looks and is called, as long as it fills the requirements. If we dont like web services we can always wrap with a neater API, as long at it provides the functionality we want, including speed. For example i suggest that we write compatibility layers or backends for XPCOM, COM. DBus and all other libraries that are still in use. With that i mean that a COM implementation should be able to communicate using the new IPC API, not necessarily with other non-COM services. 

Also Xorg should have a backand that use this API for both local and network-transparent communication, as it will provide both. This should really simplify the X11 protocol a lot. :)
Even just using Web Services with Fast Infoset rather then the current network protocol would probably simplify X11 and most other old network protocols a lot, while delivering superior speed.

Also designing something to work on all platforms including Windows will help bridge the #1-bug as it may lure Windows developers away from COM and other Windows-specific technology.

> 
> 
> > Now with Windows as a supervisor rather then a classic operating
> system,
> 
> What do you mean with this "supervisor"?
I mean as a OS that does not have any access to hardware resources except trough a hypervisor, like Xen, KVM or Hyper-V.
So what i really suggest here is to have a "Ubuntu Hypervisor" that is actually KVM and its dependencies, including drivers. The other spins of Ununtu would then be everything needed to run inside KVM and other Hypervisors. Eventually this should evolve into two software components that has very little in common. For exemple the "Ubuntu Hypervisor" does not need an advanced scheduler, or anything that is not required to run one or several supervisors. The supervisor in turn do not need hardware drivers, just drivers for the hypervisors.

If we do this split in Linux then Microsoft will be stressed to do this split in the client version of Windows. They already have Hyper-V integrated with their Windows Server stressed by VmWare.
The key issue here is really DirectX. It is problematic because its current implementation does not support this kind of visualization. This currently makes Direct X limited to Hyper-V where it can break the hypervisor-supervisor boundary and have direct access to hardware. The other solution is to move DirectX hardware abstraction to Hyper-V so that it can be similarly supported by other hypervisors. After all Microsoft wants Windows to run everywhere. However if they expect people with KVM, VmWare or VirtualBox to wanna use Windows as a supervisor KVM must work there so they must work on enabling that. On the other hand this means that with Direct X in the hypervisor, Linux as a supervisor can have a driver to access this and provide native DirectX support in Wine for example.

Windows currently have about 91% desktop/client usage-share and that's going down. If they want the other 9% to buy Windows they will need to adapt to KVM, VirtualBox etc. But in doing so they will open up for Linux and FOSS to spread like fire. Its similar to a prisoners dilemma. The pile of money that this 9% can provide and lose their vendor lock-in. Or keep the vendor lock in and be locked out from desktops that does not run Windows or Hyper-V. Even if they initially chose not to go for the first option that pile of money will still be there and whenever they desperately need to boost sales like when Vista failed the temptation may overwhelm them - and we will have won.

So basically by standardizing around having the hypervisor (KVM) as a base system we are telling Microsoft suits, "Hej, you can have our users money". While the long term effect of falling for this trick would be both disastrous and obvious for them, they live in a quarter-based economy. Having high market shares in five years is not always as important as providing a good report this quarter.  They may not even work at Microsoft in five years, but need their CV to look good.

There is also other reasons for this. It would have benefits to have a stable base system and contain most possible problems to a supervisor. Migration to a new version of Ubuntu is a lot less painless if you can run it side by side with the old version. Live migration is also cool but of limited value on the desktop. 

Another thing I also wrote about was code redundancy. Modular code does wonders when eliminating code redundancy. While splitting the kernel apart like this does only provides some modularity it still enables both components to be more flexible. For example Linux and BSD developers could work together and develop a single hypervisor, while still having different supervisor-level code. There is already a port of KVM to FreeBSD which is exactly what i envision when i talk about decreasing code redundancy. Seing components such as KVM as not a Linux component but an independent component makes it far more usable. I first started thinking about this when libATA was introduced. Seeing such components as libraries rather then part of Linux makes it possible to share them. I think i talked about OSKit previously, and this fits the OSKit philosophy. I dont think that we can ever just merge all FOSS kernels together, but that does not makes it impossible to have a small but growing number of kernel-level libraries like KVM that is shared among them. This would still allow kernel-specific patches and tweaks. For example what is a kernel-level library in Linux and BSD may be banished to user-space in a microkernel-based system.

> 
> -- 
> Martin Wildam
> 
> http://www.google.com/profiles/mwildam