osfree.org

#715 From: "Tom Lee Mullins" <tomleem@...>
Date: Fri Aug 15, 2003 4:05 pm
Subject: An E-Mail to IBM? bigwarpguy
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°


I sent an 'e-mail' (via the feedback at
http://www.ibm.com ) about supporting this project
(as well as FreePM at http://frepm.sourceforge.net ).
I said it would show their support for open source plus
allow them to comply with M$ in eventually dropping OS/2
yet Warp users to continue with the operating system that
they love. If they support Linux (they have a counter
lawsuite against CRO [IIRC on the company name]), why not
support this open source project?

BigWarpGuy

#716 From: John P Baker <jbaker314@...>
Date: Sat Aug 16, 2003 2:08 am
Subject: Re: Re: Building an OS/2 Replacement jbakersc
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°


The OS2TCS-DOC group currently has 17 members.

The OS2TCS-ADVOCACY group currently has 8 members. No messages yet on
this group, but I have been busy the last several days and have not had
time to get
anything going. However, I expect that to change over the weekend.

John P Baker

Tom Lee Mullins wrote:

> --- In osFree@yahoogroups.com, John P Baker <jbaker314@e...> wrote:
> > I have created a new Yahoo group, OS2TCS-ADVOCACY, whose purpose
> > is stated as follows:
> >
> > The purpose of this group is to discuss the creation of
> > an OS/2 follow-on meeting the requirements of the Department of
> > Defense Trusted Computer System Evaluation Criteria.
> >
> > The OS2TCS-DOC group was previously established and is currently
> > active.
> >
> > Other OS2TCS-xxx groups will be established in the future as
> > the need arises.
> >
> > This group has been marked private, and all memberships must be
> > approved by the moderator (i.e., "me").
> >
> > To subscribe to this group, send an email to
> >
> > os2tcs-advocacy-subscribe@yahoogroups.com
> >
> > John P Baker
>
> Has there been many signup/join the new group?
>
> BigWarpGuy

#717 From: "phisiker2000" <joern.knie@...>
Date: Sun Aug 17, 2003 12:34 am
Subject: Re: Building an OS/2 Replacement phisiker2000
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°


Hello,

you wrote:
>Having OS/2 layer on top of such different system as *nix is not good
> idea.

Why? I don't see now the reason (ok. from the point of breaking the
architecture,
I see it), wine is running too on a *nix-system and OS/2 is nearer at *nix than
Windows (my opinion, this is a conclusion because of the ported *nix-software,
which was available longer than the Windows-Ports). I guess, that there are more
drivers for Linux than for ReactOS in the near future, and the publicity would
help
for such a project to get more support.

Second point: What speaks against working together with Wine, if they themselves
work together with the ReactOS-Team?

I know, that it is not easy to giveup the idea of a systemarchitecture (I don't
know
exactly, what yours is) but the goal is, the get a running, stable and free
replacement of OS/2. If there is a way to do it faster with still appropriate
architecture, why not use this one?

There was already some effort to create a replacement and all failed,
unfortunately. I could live with a native replacement, no problem, but until now
there is no free OS/2-derivate available and this could keep so, until OS/2 died
definitively! The time is running and has no pity on our brilliant ideas, which
we
want to realize.

--- In osFree@yahoogroups.com, yuri_prokushev@m... wrote:
> * Answer on message from INET.OSFREE area
>
> Hello!
>
> Answer on message from phisiker2000 to osFree@yahoogroups.com:
>
> p> I would be already happy to be able to run OS/2-programs on a
> p> different
> p> platform (Linux prefered). Why not participate at Wine to integrate
> p> a
> p> OS/2-layer? This would be a good first step for a free OS/2-
> p> replacement:
>
> p> 1.) The OS/2-Software would be able to run Win32-binaries without
> p> the
> p> need to rewrite all
> p> 2.) The design of the Win32-controls can be adapted to the OS/2-
> p> design
> p> 3.) The execution of OS/2-binaries could be done on different OS
> p> (Linux, ReactOS, ...)
> p> 4.) A native OS/2-Kernel can be implemented later, but the first
> p> success would be quite fast and help to acquire more developers.
>
> Having OS/2 layer on top of such different system as *nix is not good
> idea. If use another OS as base then I prefer to use ReactOS (WinNT)
> because architecture allows to do such things. Just OS/2 subsystem can
> be implemented without worring about kernel & drivers.
>
>
> CU!
>
> Yuri Prokushev
> prokushev at freemail dot ru [http://sibyl.netlabs.org]

#718 From: "Lynn H. Maxson" <lmaxson@...>
Date: Sun Aug 17, 2003 6:36 am
Subject: Re: Re: Building an OS/2 Replacement lynnmaxson
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°


"Why? I don't see now the reason (ok. from the point of
breaking the architecture, I see it), wine is running too on a
*nix-system and OS/2 is nearer at *nix than Windows (my
opinion, this is a conclusion because of the ported
nix-software, which was available longer than the
Windows-Ports). ..."

Like the man says, it sounds like deju vu all over again. It
relates to the reason that two mailing lists, osfree and freeos,
exist. One, osfree, sought a microkernel implementation. The
other, freeos, sought a layered implementation. Both have
effectively faltered for lack of committed resources, not
interest.

If you don't have the resources, i.e. if you are limited in some
manner, you would normally make a decision based on which
approach offers to make the most of the resources you have.
You have two things to consider. One, which requires the
least effort to produce an initial version. Two, which requires
the least effort to maintain over time. Development and
maintenance.

I know that you have WINE, ODIN, and Lindows, all offering a
layered approach. Yet none of them after years of effort
offer a complete solution in terms of complete support. You
place too much emphasis on partial success as if it were only
a matter of time before you had complete success.

The problems with any layered approach begins with the
dynamics, the changes which will occur over time, between
the layers and the need to do double maintenance to keep
them in sync. They do not proceed hand-in-hand as the
interests of the "base" OS group only partially overlap at best
those of the "based".

To somehow have an agreement in principle for both to
proceed apace, i.e. in sync, means making decisions based on
larger concerns of keeping both in sync than any you would
have to make for either alone. In short, the maintenance
effort for both groups increases due to concerns for the
impact on the other as do the problems which arise from
functional conflicts.

You need more resources to maintain both together than you
do apart. In short Linux already exists without a need for
OS/2. No incentive exists for Linux users to suddenly now
entwine their future with that of OS/2. It exists only for the
OS/2 users. Given the resource constraints, particularly for
OS/2, why would either group select a method which
increased those constraints even further?

What's not clear to you, for which nothing in terms of formal
proof exists, unless you what to consider the continuing
incomplete status of WINE and ODIN as such, is that it requires
less effort to build a standalone OS from scratch than to
layered it on top of another. Not even VPC escapes this.

Yet a microkernel-based OS/2 would allow a concurrent
version of Linux or Windows to reside and execute, providing
both used the same microkernel. I think that's what makes
REACTOS so attractive to some, though I have no experience
with it. It allows all groups to maintain their OSes separately
without concern for any other, reducing the overall effort.

The problem here is Linux and getting the kernel away from
Linux Torvalds. The answer lies in dumping the current Linux
kernel for a microkernel replacement and then writing an OS/2
clone based on it as well. Then take the ODIN and WINE
source to write a microkernel clone of Windows. Now you
have the functionality of all three in a single operating
environment.

However, if you really feel like doing more work than
absolutely necessary, then certainly the layered approach is
your choice.<g>

Finally, the discussion group which has been formed would do
well to read "OS/2 Warp (PowerPC Edition), A First Look" as
part of their documentation effort. I would be happy to send
it to anyone on request.

#719 From: "phisiker2000" <joern.knie@...>
Date: Sun Aug 17, 2003 4:14 pm
Subject: Re: Building an OS/2 Replacement phisiker2000
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°


Will your problem really the interface between the underlying OS and your layer
be? I'm not convinced about that and I think that your problem will be (like in
the
WINE-Team) the partially undocumented (and under Windows often changing) API!
The interfaces to *nix-Systems are metastatic, so that I would not have such
doubts.

But sure, there could be some work to do if in the underlying architecture is
something changeing. But to maintain (and develop) a selfmade kernel needs time
too. You see, how long it sometimes takes, until a driver is written or Linux if
the
manufacturer does not give the needed hardwarespecifications?

OK, if the member of this group want to begin on the kernel-layer, just go on.
This
is really not a problem for me, just the time to wait for support for my
problems will
take longer, so that I will think about to migrate from OS/2 away (excuse me, I
am waiting for years and a desicion will be to do in the near future. This has
nothing to do with your answer as I would not accept your desicion. But a
timehorizon of ten years or more for a good software- and hardwaresupport is too
long for me).

--- In osFree@yahoogroups.com, "Lynn H. Maxson" <lmaxson@p...> wrote:
> "Why? I don't see now the reason (ok. from the point of
> breaking the architecture, I see it), wine is running too on a
> *nix-system and OS/2 is nearer at *nix than Windows (my
> opinion, this is a conclusion because of the ported
> nix-software, which was available longer than the
> Windows-Ports). ..."
>
> Like the man says, it sounds like deju vu all over again. It
> relates to the reason that two mailing lists, osfree and freeos,
> exist. One, osfree, sought a microkernel implementation. The
> other, freeos, sought a layered implementation. Both have
> effectively faltered for lack of committed resources, not
> interest.
>
> If you don't have the resources, i.e. if you are limited in some
> manner, you would normally make a decision based on which
> approach offers to make the most of the resources you have.
> You have two things to consider. One, which requires the
> least effort to produce an initial version. Two, which requires
> the least effort to maintain over time. Development and
> maintenance.
>
> I know that you have WINE, ODIN, and Lindows, all offering a
> layered approach. Yet none of them after years of effort
> offer a complete solution in terms of complete support. You
> place too much emphasis on partial success as if it were only
> a matter of time before you had complete success.
>
> The problems with any layered approach begins with the
> dynamics, the changes which will occur over time, between
> the layers and the need to do double maintenance to keep
> them in sync. They do not proceed hand-in-hand as the
> interests of the "base" OS group only partially overlap at best
> those of the "based".
>
> To somehow have an agreement in principle for both to
> proceed apace, i.e. in sync, means making decisions based on
> larger concerns of keeping both in sync than any you would
> have to make for either alone. In short, the maintenance
> effort for both groups increases due to concerns for the
> impact on the other as do the problems which arise from
> functional conflicts.
>
> You need more resources to maintain both together than you
> do apart. In short Linux already exists without a need for
> OS/2. No incentive exists for Linux users to suddenly now
> entwine their future with that of OS/2. It exists only for the
> OS/2 users. Given the resource constraints, particularly for
> OS/2, why would either group select a method which
> increased those constraints even further?
>
> What's not clear to you, for which nothing in terms of formal
> proof exists, unless you what to consider the continuing
> incomplete status of WINE and ODIN as such, is that it requires
> less effort to build a standalone OS from scratch than to
> layered it on top of another. Not even VPC escapes this.
>
> Yet a microkernel-based OS/2 would allow a concurrent
> version of Linux or Windows to reside and execute, providing
> both used the same microkernel. I think that's what makes
> REACTOS so attractive to some, though I have no experience
> with it. It allows all groups to maintain their OSes separately
> without concern for any other, reducing the overall effort.
>
> The problem here is Linux and getting the kernel away from
> Linux Torvalds. The answer lies in dumping the current Linux
> kernel for a microkernel replacement and then writing an OS/2
> clone based on it as well. Then take the ODIN and WINE
> source to write a microkernel clone of Windows. Now you
> have the functionality of all three in a single operating
> environment.
>
> However, if you really feel like doing more work than
> absolutely necessary, then certainly the layered approach is
> your choice.<g>
>
> Finally, the discussion group which has been formed would do
> well to read "OS/2 Warp (PowerPC Edition), A First Look" as
> part of their documentation effort. I would be happy to send
> it to anyone on request.

#720 From: "Lynn H. Maxson" <lmaxson@...>
Date: Sun Aug 17, 2003 6:43 pm
Subject: Re: Re: Building an OS/2 Replacement lynnmaxson
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°


"Will your problem really the interface between the
underlying OS and your layer be? I'm not convinced about that
and I think that your problem will be (like in the
WINE-Team) the partially undocumented (and under Windows
often changing) API! The interfaces to *nix-Systems are
metastatic, so that I would not have such doubts. ..."

I make the simple assertion that you would find it less effort
(and time) to make a "complete" clone as a standalone
version than attempting it as a layer. The reason lies in the
API layers involved, that of the guest OS (in this instance
OS/2) and the host (Linux or Unix). The layered approach has
to take in consideration the same challenges that a
non-layered does with respect to application support.

The layered approach has three layered interactions
(application, guest OS, host OS) whereas the non-layered
approach has two (application, host OS). The layered has
two API levels to continually reconcile, while the non-layered
has only one. The layered approach then requires knowledge
of two OSes, while the non-layered only one.

I place the emphasis earlier on the word "complete" to set it
apart from "incomplete" as offered by WINE and ODIN.
Whatever the reasons offered comes the acceptance of only
partial success. You can't have partial success in an OS/2
replacement, because you have product sources, e.g. eCS,
which are "complete". That's why distributors offer Windows
pre-intalled instead of Linux and WINE or OS/2 and ODIN.

At a given API layer the issues do not lie above it, which must
conform to the API rules, but below it, which must support
them. That says if you have one API layer "above" the other,
as you do in a layered approach, that the one above must
conform to the one below.

That says for "functional" completeness that you must have a
"below" API as a proper subset of the "above". If they
conflict or differ in any manner, then the above must resort to
filters to resolve differences or must create "system" code
which somehow must bypass the below API (which it cannot
use) to something which supports it. If no such support exists
at any lower level, then the "above" level must somehow
provide it.

Now remember that an API consists of a name, a set of
ordered parameters, frequently a value range for those
parameters on input and output, and a set of return codes.
Thus any mapping of one API layer on another must resolve
any differences that exist. This does not take into account
other functional "nuances" that may differ between the two
as well.

Thus the API layer "dictates" both up and down. In either
direction it expects conformity or support. A layered
approach with a guest OS cannot dictate terms to the host OS.
You will find this particularly true when the host OS has an
independent life of its own relative to its own needs and
desires.

If you look at a microkernel(uK), it represents a "base" layer
for an OS required by all intervening layers up to and
including the OS API, the application layer. Now allow me to
quote from the IBM Redbook on "OS/2 Warp (PowerPC
Edition)".

"The IBM microkernel provides the following comprehensive
environment for operating systems:
* Multiprocessing
* Multithreading
* Interprocess communication
* Extensible memory management
* Support for multiple operating personalities"

"The types of services are:
1. Physical resource management
2. I/O support and interrupt management
3. Interprocess communication (IPC)
4. Tasks and threads
5. Virtual memory management"

The virtual memory management enables portability to 32-
and 64-bit platforms.

Like any API layer the "base" layer dictates the terms to the
higher layers. It dictates it in a manner "common" to multiple
host OS API layers with the broadest possible range of
support. That means at the very least this base or uK API
layer is a superset of the functional needs of a host OS API,
an OS personality;at the most, matches it exactly.

That means you can write a "complete" replacement for OS/2,
Linux, Unix, or Windows with the additional benefit of having
a single environment for their concurrent execution. It
requires no compromise or loss of functionality along with the
complete identity of the API: name, parameters, order, value
range, and return codes.

I have not evaluated the Mach kernel versus that of REACTOS.
I can only assume that it is easier to write an OS/2 API layer
based on a "base" API layer without restrictions than on
another OS API layer with them. That should allow both the
WINE and ODIN groups to merge to produce a "complete"
Windows OS without concerns for an underlying host OS layer.

It's just easier for everyone.<g> At least that's one man's
opinion.

#721 From: "Tom Lee Mullins" <tomleem@...>
Date: Sun Aug 17, 2003 10:34 pm
Subject: Re: Building an OS/2 Replacement bigwarpguy
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°


--- In osFree@yahoogroups.com, John P Baker <jbaker314@e...> wrote:
> The OS2TCS-DOC group currently has 17 members.
>
> The OS2TCS-ADVOCACY group currently has 8 members. No
> messages yet on this group, but I have been busy the last
> several days and have not had time to get anything going.
> However, I expect that to change over the weekend.
>
> John P Baker
>
> Tom Lee Mullins wrote:
>
....
...
> > Has there been many signup/join the new group?
> >
> > BigWarpGuy

I find that number (even the existance of the group) to be
very encouraging.

BigWarpGuy

#722 From: John P Baker <jbaker314@...>
Date: Mon Aug 18, 2003 3:33 am
Subject: Re: Re: Building an OS/2 Replacement jbakersc
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°


Well, I am glad to see that my project has raised reignited interest here.

As far as building on top of LINUX, I would have to say no. The reasons
given by Lynn are a good start. However, there are other reasons, which
in this case, are of much greater significance.

The goal of my project is to build a system compliant with the Department
of Defense Trusted Computer System Evaluation Criteria, and more
specifically, with security classification A1, "Verified Design".

To my knowledge, no existing system meets the verified design criteria,
nor do I believe that any existing system can be refit to meet those
criteria.

Such a system MUST be designed and constructed from the ground up to
meet the stringent criteria required for "Verified Design".

John P Baker

Lynn H. Maxson wrote:

> "Will your problem really the interface between the
> underlying OS and your layer be? I'm not convinced about that
> and I think that your problem will be (like in the
> WINE-Team) the partially undocumented (and under Windows
> often changing) API! The interfaces to *nix-Systems are
> metastatic, so that I would not have such doubts. ..."
>
> I make the simple assertion that you would find it less effort
> (and time) to make a "complete" clone as a standalone
> version than attempting it as a layer. The reason lies in the
> API layers involved, that of the guest OS (in this instance
> OS/2) and the host (Linux or Unix). The layered approach has
> to take in consideration the same challenges that a
> non-layered does with respect to application support.
>
> The layered approach has three layered interactions
> (application, guest OS, host OS) whereas the non-layered
> approach has two (application, host OS). The layered has
> two API levels to continually reconcile, while the non-layered
> has only one. The layered approach then requires knowledge
> of two OSes, while the non-layered only one.
>
> I place the emphasis earlier on the word "complete" to set it
> apart from "incomplete" as offered by WINE and ODIN.
> Whatever the reasons offered comes the acceptance of only
> partial success. You can't have partial success in an OS/2
> replacement, because you have product sources, e.g. eCS,
> which are "complete". That's why distributors offer Windows
> pre-intalled instead of Linux and WINE or OS/2 and ODIN.
>
> At a given API layer the issues do not lie above it, which must
> conform to the API rules, but below it, which must support
> them. That says if you have one API layer "above" the other,
> as you do in a layered approach, that the one above must
> conform to the one below.
>
> That says for "functional" completeness that you must have a
> "below" API as a proper subset of the "above". If they
> conflict or differ in any manner, then the above must resort to
> filters to resolve differences or must create "system" code
> which somehow must bypass the below API (which it cannot
> use) to something which supports it. If no such support exists
> at any lower level, then the "above" level must somehow
> provide it.
>
> Now remember that an API consists of a name, a set of
> ordered parameters, frequently a value range for those
> parameters on input and output, and a set of return codes.
> Thus any mapping of one API layer on another must resolve
> any differences that exist. This does not take into account
> other functional "nuances" that may differ between the two
> as well.
>
> Thus the API layer "dictates" both up and down. In either
> direction it expects conformity or support. A layered
> approach with a guest OS cannot dictate terms to the host OS.
> You will find this particularly true when the host OS has an
> independent life of its own relative to its own needs and
> desires.
>
> If you look at a microkernel(uK), it represents a "base" layer
> for an OS required by all intervening layers up to and
> including the OS API, the application layer. Now allow me to
> quote from the IBM Redbook on "OS/2 Warp (PowerPC
> Edition)".
>
> "The IBM microkernel provides the following comprehensive
> environment for operating systems:
> * Multiprocessing
> * Multithreading
> * Interprocess communication
> * Extensible memory management
> * Support for multiple operating personalities"
>
> "The types of services are:
> 1. Physical resource management
> 2. I/O support and interrupt management
> 3. Interprocess communication (IPC)
> 4. Tasks and threads
> 5. Virtual memory management"
>
> The virtual memory management enables portability to 32-
> and 64-bit platforms.
>
> Like any API layer the "base" layer dictates the terms to the
> higher layers. It dictates it in a manner "common" to multiple
> host OS API layers with the broadest possible range of
> support. That means at the very least this base or uK API
> layer is a superset of the functional needs of a host OS API,
> an OS personality;at the most, matches it exactly.
>
> That means you can write a "complete" replacement for OS/2,
> Linux, Unix, or Windows with the additional benefit of having
> a single environment for their concurrent execution. It
> requires no compromise or loss of functionality along with the
> complete identity of the API: name, parameters, order, value
> range, and return codes.
>
> I have not evaluated the Mach kernel versus that of REACTOS.
> I can only assume that it is easier to write an OS/2 API layer
> based on a "base" API layer without restrictions than on
> another OS API layer with them. That should allow both the
> WINE and ODIN groups to merge to produce a "complete"
> Windows OS without concerns for an underlying host OS layer.
>
> It's just easier for everyone.<g> At least that's one man's
> opinion.

#723 From: Dale Erwin <daleerwin@...>
Date: Mon Aug 18, 2003 3:25 am
Subject: Re: Re: Building an OS/2 Replacement dale_erwin
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°


phisiker2000 wrote:
> Will your problem really the interface between the underlying OS and your
layer
> be? I'm not convinced about that and I think that your problem will be (like
in the
> WINE-Team) the partially undocumented (and under Windows often changing) API!
> The interfaces to *nix-Systems are metastatic, so that I would not have such
> doubts.
>
> But sure, there could be some work to do if in the underlying architecture is
> something changeing. But to maintain (and develop) a selfmade kernel needs
time
> too. You see, how long it sometimes takes, until a driver is written or Linux
if the
> manufacturer does not give the needed hardwarespecifications?
>
> OK, if the member of this group want to begin on the kernel-layer, just go on.
This
> is really not a problem for me, just the time to wait for support for my
problems will
> take longer, so that I will think about to migrate from OS/2 away (excuse me,
I
> am waiting for years and a desicion will be to do in the near future. This has
> nothing to do with your answer as I would not accept your desicion. But a
> timehorizon of ten years or more for a good software- and hardwaresupport is
too
> long for me).

Without a new kernel, you will NEVER have an open source replacement
for OS/2. IBM will NEVER release the source. If I understand correctly,
they cannot do so because of code licensing from Microsoft and others. There
is also the fact that an ODIN-type solution will be a never-ending project.
The time required for a new kernel before anything can be used may well be
longer, but the way I see it is that anything less will be the same as using
band-aids to suture a surgical incision, and will have the effect of
perpetuating
the problem.
--
Dale Erwin
Salamanca 116
Pueblo Libre
Lima 21 PERU
Tel. +51(1)461-3084
Cel. +51(1)9743-6439

#724 From: "Lynn H. Maxson" <lmaxson@...>
Date: Mon Aug 18, 2003 5:51 am
Subject: Re: Re: Building an OS/2 Replacement lynnmaxson
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°


Dale Erwin writes (in response to phisiker2000);
"...The time required for a new kernel before anything can be
used may well be longer, but the way I see it is that anything
less will be the same as using band-aids to suture a surgical
incision, and will have the effect of perpetuating the
problem."

We might have some dispute with respect to "before anything
can be used", implying a partially complete state. The
"anything" here relates to a specific application or set of
applications. I think you correct in that a layered approach
like ODIN and WINE is a "never complete" project. That alone
should discourage use of a layered approach here.

I actually question whether it will take longer. As I said in an
earlier response I have to actual proof or empirical evidence,
but my "gut" feel, given the selection of a "viable" uK, says it
should take less time over time. That means that a layered
approach may offer something "quick and dirty" early on but
will suffer longer and longer intervals between meaningful
milestones. Whereas in the uK approach the initial milestone
may occur later but the intervals for successive ones will be
shorter. The end result is that you will have a "complete"
replacement for the OS/2 kernel, i.e. the API support, while
the layered approach will never complete and only terminate
eventually through exhaustion.

What gets lost in this debate in terms of replacement is the
difference between replacing the IBM OS/2 "kernel" and
replacing the IBM "package" of bundled software, including
utilities etc.. These latter are the things which must run in the
kernel's application layer.

Replacing the IBM OS/2 kernel while significant is far less than
the much larger package. Secondly it makes little sense to
replace it without in some sense providing something extra,
some reason for an existing OS/2 user say like me with his
Warp 4 with fixpak 15 to make the change. I have two
shrinkwrapped copies of eCS 1.0. I'm not seriously considering
updating them to 1.1 as I have yet to come up with some
reason to do so.

I'm not sure with an open source OS/2 replacement that
Serenity Systems would consider shifting more to the same
role that Red Hat serves in the Linux community. I have in
SCOUG listened to Kim Cheung reasons for, one, being in the
business, and, two, staying there.

The point is that anything less than a complete kernel
replacement is insufficient as is anything which is not more.
So you have to ask yourself, "What constitutes more?" The
best answer lies in improved hardware support. It would be
nice not to have to port Linux drivers, but simply use them. it
would be nice to have a greater choice of motherboards. It
would be nice to have SMP support. It would be nice to have
64-bit addressing support.

I'm not sure that a layered support could use Linux device
drivers without considerable effort as it would have to offer a
filter interface to support existing OS/2 device drivers as well
as new Linux ones. Unless your Linux kernel supports 64-bits
your OS/2 replacement will not. Similar arguments exist for
the other hardware "niceties".

The only question I have about a uK approach lies in the
presentation services, the software that supports the GUI. I
don't know how you can have a "common" service that
supports multiple OSes concurrently, i.e. viewed at the same
time on the display. I don't know that anyone has ever gotten
to the two OSes level with different GUIs to see how that
works...if it works at all.

But there is no doubt that the uK approach can work for OS/2
for the simple reason that it has. I don't think there is any
doubt that a bootable uK-based replacement for the OS/2
kernel, which is a simple plug-and-play for any prospective
user, if successful will more quickly increase the momentum to
finish the job with respect to the entire package.