Very Computer

> Supposedly microkernel design is supposed to make it that much easier for
> the kernel to be ported to various hardware architectures in addition to
> other dubious benefits.

> But what I've seen is that many platforms that tout a so-called
> microkernel are not easily ported despite the arguments to the contrary.

> Is this because of lack of interest or is it being proven via real world
> example that the whole microkernel porting thing is inherently incorrect?

> A perfect example of this is the latest 64bit AMD Hammer chips.  Now,
> supposedly, the Windows NT family is built off of a microkernel design. As
> such, it should have been able to be ported to this new arch fairly
> quickly.  OTOH, Linux, which is a macrokernel, should have been a PIA to
> port over to this new arch.

> But what we see is exactly the opposite: the macrokernel platform (Linux)
> was ported first and the microkernel platform (Windows) still isn't
> available.  The same for many other architectures.

> So what is one to make of that?  Is it simply a matter of manpower or are
> there technological issues that should be considered?

> So what is one to make of that?  Is it simply a matter of manpower or are
> there technological issues that should be considered?

>> I'm curious as to the whole microkernel vs. macrokernel archtiecture
>> scheme.

>> Supposedly microkernel design is supposed to make it that much easier
>> for the kernel to be ported to various hardware architectures in
>> addition to other dubious benefits.

>> But what I've seen is that many platforms that tout a so-called
>> microkernel are not easily ported despite the arguments to the
>> contrary.

>> Is this because of lack of interest or is it being proven via real
>> world example that the whole microkernel porting thing is inherently
>> incorrect?

>> A perfect example of this is the latest 64bit AMD Hammer chips.  Now,
>> supposedly, the Windows NT family is built off of a microkernel design.
>> As such, it should have been able to be ported to this new arch fairly
>> quickly.  OTOH, Linux, which is a macrokernel, should have been a PIA
>> to port over to this new arch.

>> But what we see is exactly the opposite: the macrokernel platform
>> (Linux) was ported first and the microkernel platform (Windows) still
>> isn't
>> available.  The same for many other architectures.

>> So what is one to make of that?  Is it simply a matter of manpower or
>> are there technological issues that should be considered?

> There are technological issues to be considered. Such as compatibility
> with existing applications without a recompile.

> Let's see the Linux distro which manages *that*.

>> I'm curious as to the whole microkernel vs. macrokernel archtiecture
>> scheme.

>> Supposedly microkernel design is supposed to make it that much easier for
>> the kernel to be ported to various hardware architectures in addition to
>> other dubious benefits.

>> But what I've seen is that many platforms that tout a so-called
>> microkernel are not easily ported despite the arguments to the contrary.

>> Is this because of lack of interest or is it being proven via real world
>> example that the whole microkernel porting thing is inherently incorrect?

>> A perfect example of this is the latest 64bit AMD Hammer chips.  Now,
>> supposedly, the Windows NT family is built off of a microkernel design. As
>> such, it should have been able to be ported to this new arch fairly
>> quickly.  OTOH, Linux, which is a macrokernel, should have been a PIA to
>> port over to this new arch.

>> But what we see is exactly the opposite: the macrokernel platform (Linux)
>> was ported first and the microkernel platform (Windows) still isn't
>> available.  The same for many other architectures.

>> So what is one to make of that?  Is it simply a matter of manpower or are
>> there technological issues that should be considered?

> There are technological issues to be considered. Such as compatibility with
> existing applications without a recompile.

> Let's see the Linux distro which manages *that*.

>>> I'm curious as to the whole microkernel vs. macrokernel archtiecture
>>> scheme.

>>> Supposedly microkernel design is supposed to make it that much easier
>>> for the kernel to be ported to various hardware architectures in
>>> addition to other dubious benefits.

>>> But what I've seen is that many platforms that tout a so-called
>>> microkernel are not easily ported despite the arguments to the
>>> contrary.

>>> Is this because of lack of interest or is it being proven via real
>>> world example that the whole microkernel porting thing is inherently
>>> incorrect?

>>> A perfect example of this is the latest 64bit AMD Hammer chips.  Now,
>>> supposedly, the Windows NT family is built off of a microkernel design.
>>> As such, it should have been able to be ported to this new arch fairly
>>> quickly.  OTOH, Linux, which is a macrokernel, should have been a PIA
>>> to port over to this new arch.

>>> But what we see is exactly the opposite: the macrokernel platform
>>> (Linux) was ported first and the microkernel platform (Windows) still
>>> isn't
>>> available.  The same for many other architectures.

>>> So what is one to make of that?  Is it simply a matter of manpower or
>>> are there technological issues that should be considered?

>> There are technological issues to be considered. Such as compatibility
>> with existing applications without a recompile.

>> Let's see the Linux distro which manages *that*.

> Lets see the windows version which manages *that*

>>>> I'm curious as to the whole microkernel vs. macrokernel archtiecture
>>>> scheme.

>>>> Supposedly microkernel design is supposed to make it that much easier
>>>> for the kernel to be ported to various hardware architectures in
>>>> addition to other dubious benefits.

>>>> But what I've seen is that many platforms that tout a so-called
>>>> microkernel are not easily ported despite the arguments to the
>>>> contrary.

>>>> Is this because of lack of interest or is it being proven via real
>>>> world example that the whole microkernel porting thing is inherently
>>>> incorrect?

>>>> A perfect example of this is the latest 64bit AMD Hammer chips.  Now,
>>>> supposedly, the Windows NT family is built off of a microkernel
>>>> design. As such, it should have been able to be ported to this new
>>>> arch fairly
>>>> quickly.  OTOH, Linux, which is a macrokernel, should have been a PIA
>>>> to port over to this new arch.

>>>> But what we see is exactly the opposite: the macrokernel platform
>>>> (Linux) was ported first and the microkernel platform (Windows) still
>>>> isn't
>>>> available.  The same for many other architectures.

>>>> So what is one to make of that?  Is it simply a matter of manpower or
>>>> are there technological issues that should be considered?

>>> There are technological issues to be considered. Such as compatibility
>>> with existing applications without a recompile.

>>> Let's see the Linux distro which manages *that*.

>> Lets see the windows version which manages *that*

> NT 4.0 Alpha.

> Next?

> Simon

> >>>> I'm curious as to the whole microkernel vs. macrokernel
archtiecture
> >>>> scheme.

> >>>> Supposedly microkernel design is supposed to make it that much
easier
> >>>> for the kernel to be ported to various hardware architectures in
> >>>> addition to other dubious benefits.

> >>>> But what I've seen is that many platforms that tout a so-called
> >>>> microkernel are not easily ported despite the arguments to the
> >>>> contrary.

> >>>> Is this because of lack of interest or is it being proven via
real
> >>>> world example that the whole microkernel porting thing is
inherently
> >>>> incorrect?

> >>>> A perfect example of this is the latest 64bit AMD Hammer chips.
Now,
> >>>> supposedly, the Windows NT family is built off of a microkernel
> >>>> design. As such, it should have been able to be ported to this
new
> >>>> arch fairly
> >>>> quickly.  OTOH, Linux, which is a macrokernel, should have been a
PIA
> >>>> to port over to this new arch.

> >>>> But what we see is exactly the opposite: the macrokernel platform
> >>>> (Linux) was ported first and the microkernel platform (Windows)
still
> >>>> isn't
> >>>> available.  The same for many other architectures.

> >>>> So what is one to make of that?  Is it simply a matter of
manpower or
> >>>> are there technological issues that should be considered?

> >>> There are technological issues to be considered. Such as
compatibility
> >>> with existing applications without a recompile.

> >>> Let's see the Linux distro which manages *that*.

> >> Lets see the windows version which manages *that*

> > NT 4.0 Alpha.

> > Next?

> > Simon

> Wrong

>>>> I'm curious as to the whole microkernel vs. macrokernel archtiecture
>>>> scheme.

>>>> Supposedly microkernel design is supposed to make it that much easier
>>>> for the kernel to be ported to various hardware architectures in
>>>> addition to other dubious benefits.

>>>> But what I've seen is that many platforms that tout a so-called
>>>> microkernel are not easily ported despite the arguments to the
>>>> contrary.

>>>> Is this because of lack of interest or is it being proven via real
>>>> world example that the whole microkernel porting thing is inherently
>>>> incorrect?

>>>> A perfect example of this is the latest 64bit AMD Hammer chips.  Now,
>>>> supposedly, the Windows NT family is built off of a microkernel design.
>>>> As such, it should have been able to be ported to this new arch fairly
>>>> quickly.  OTOH, Linux, which is a macrokernel, should have been a PIA
>>>> to port over to this new arch.

>>>> But what we see is exactly the opposite: the macrokernel platform
>>>> (Linux) was ported first and the microkernel platform (Windows) still
>>>> isn't
>>>> available.  The same for many other architectures.

>>>> So what is one to make of that?  Is it simply a matter of manpower or
>>>> are there technological issues that should be considered?

>>> There are technological issues to be considered. Such as compatibility
>>> with existing applications without a recompile.

>>> Let's see the Linux distro which manages *that*.

>> Lets see the windows version which manages *that*

> NT 4.0 Alpha.

> Next?

> Simon

>> >> So what is one to make of that?  Is it simply a matter of manpower
> or
>> >> are there technological issues that should be considered?

>> > There are technological issues to be considered. Such as
> compatibility
>> > with existing applications without a recompile.

>> Oh, would that be why half of existing apps don't run on Win2003 and
> the
>> other half don't work right?

> Certainly better than the Linux solutions; aka: none of them work.

> Simon

> >>>> I'm curious as to the whole microkernel vs. macrokernel
archtiecture
> >>>> scheme.

> >>>> Supposedly microkernel design is supposed to make it that much
easier
> >>>> for the kernel to be ported to various hardware architectures in
> >>>> addition to other dubious benefits.

> >>>> But what I've seen is that many platforms that tout a so-called
> >>>> microkernel are not easily ported despite the arguments to the
> >>>> contrary.

> >>>> Is this because of lack of interest or is it being proven via
real
> >>>> world example that the whole microkernel porting thing is
inherently
> >>>> incorrect?

> >>>> A perfect example of this is the latest 64bit AMD Hammer chips.
Now,
> >>>> supposedly, the Windows NT family is built off of a microkernel
design.
> >>>> As such, it should have been able to be ported to this new arch
fairly
> >>>> quickly.  OTOH, Linux, which is a macrokernel, should have been a
PIA
> >>>> to port over to this new arch.

> >>>> But what we see is exactly the opposite: the macrokernel platform
> >>>> (Linux) was ported first and the microkernel platform (Windows)
still
> >>>> isn't
> >>>> available.  The same for many other architectures.

> >>>> So what is one to make of that?  Is it simply a matter of
manpower or
> >>>> are there technological issues that should be considered?

> >>> There are technological issues to be considered. Such as
compatibility
> >>> with existing applications without a recompile.

> >>> Let's see the Linux distro which manages *that*.

> >> Lets see the windows version which manages *that*

> > NT 4.0 Alpha.

> > Next?

> > Simon

> NT 4.0 for alpha ran the same binaries as the x86 version?

>> >>>> I'm curious as to the whole microkernel vs. macrokernel
> archtiecture
>> >>>> scheme.

>> >>>> Supposedly microkernel design is supposed to make it that much
> easier
>> >>>> for the kernel to be ported to various hardware architectures in
>> >>>> addition to other dubious benefits.

>> >>>> But what I've seen is that many platforms that tout a so-called
>> >>>> microkernel are not easily ported despite the arguments to the
>> >>>> contrary.

>> >>>> Is this because of lack of interest or is it being proven via
> real
>> >>>> world example that the whole microkernel porting thing is
> inherently
>> >>>> incorrect?

>> >>>> A perfect example of this is the latest 64bit AMD Hammer chips.
> Now,
>> >>>> supposedly, the Windows NT family is built off of a microkernel
> design.
>> >>>> As such, it should have been able to be ported to this new arch
> fairly
>> >>>> quickly.  OTOH, Linux, which is a macrokernel, should have been a
> PIA
>> >>>> to port over to this new arch.

>> >>>> But what we see is exactly the opposite: the macrokernel platform
>> >>>> (Linux) was ported first and the microkernel platform (Windows)
> still
>> >>>> isn't
>> >>>> available.  The same for many other architectures.

>> >>>> So what is one to make of that?  Is it simply a matter of
> manpower or
>> >>>> are there technological issues that should be considered?

>> >>> There are technological issues to be considered. Such as
> compatibility
>> >>> with existing applications without a recompile.

>> >>> Let's see the Linux distro which manages *that*.

>> >> Lets see the windows version which manages *that*

>> > NT 4.0 Alpha.

>> > Next?

>> > Simon

>> NT 4.0 for alpha ran the same binaries as the x86 version?

> The OS was compiled for the alpha architecture, but it would indeed run
> x86 binaries if necessary.

> You'd get a performance hit compared to native binaries, but it worked.

> Simon