registry team mailing list archive

[Faldegast <1@xxxxxxxxxxxxxxxxxx>]

> Date: Thu, 26 Aug 2010 07:42:30 +0000
> From: 1@xxxxxxxxxxxxxxxxxx
> To: faldegast@xxxxxxxxxxx
> Subject: Re: [Bug 1] Re: Microsoft has a majority market share
> 
> On Wed, Aug 25, 2010 at 23:46, Faldegast <1@xxxxxxxxxxxxxxxxxx> 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

-- 
Microsoft has a majority market share
https://bugs.launchpad.net/bugs/1
You received this bug notification because you are a member of Registry
Administrators, which is the registrant for Debian.