#725 From: Ben Ravago <ben.ravago@...>
Date: Mon Aug 18, 2003 7:24 am
Subject: Re: Re: Building an OS/2 Replacement ben_ravago
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
With regards to a microkernel implementation, I'd like to again point out the
L4KA project (www.l4ka.org). There's recently been a number of new
developments here (e.g., a Linux device driver environment) and the
mailing lists seem to indicate that people are working on interesting projects.
Part 25 - Aug 18 2003
Re: Part 25
#726 From: "Lynn H. Maxson" <lmaxson@...>
Date: Mon Aug 18, 2003 7:02 pm
Subject: Re: Re: Building an OS/2 Replacement lynnmaxson
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
Ben Ravago writes:
"With regards to a microkernel implementation, I'd like to
again point out the L4KA project (www.l4ka.org). There's
recently been a number of new developments here (e.g., a
Linux device driver environment) and the mailing lists seem to
indicate that people are working on interesting projects."
I took a look at both the L4KA and REACTOS projects. Earlier
I had a go at the MACH, the uK used as the basis for IBM's OS/2
for the PowerPC. I guess the questions that dwell in the back
of my mind lies in the meaning of "base APIs" for use in higher
level ones: in what ways do they differ and what is the
significance of the differences? In short why are they not
identical?
I'm not an object-oriented fan. As a result reading that
something is written almost entirely in C++ amounts to a
turnoff. I might as well admit I'm not a C fan either, having
some nearly 40 years experience with PL/I never needing to
resort to anything else regardless of the application...except
for OS/2 device drivers.<g>
The point is that you are engaged in documenting
specifications of a project prior to implementing it. Your only
problem is having some agreement with respect to the
sufficiency of the documentation at which point you can begin
the implementation. There are some who want to start it
"now" while there are others for whom "tomorrow" never
comes.
In all this you have to have a starting point "here", a base
layer API to get to a known ending point "there", the OS/2 API
layer. You know one, the OS/2 API layer. It is well
documented. You have to decide, i.e. know, eventually the
other, which you have to document. Then you have to
document how you get from "here" to "there": you have to
provide a "map". You have a mapping operation to document.
Only one of the suggested uKs has actually been used in the
production of OS/2, the MACH uK. I would suggest it as a
starting point without at the same time downgrading any of
the others. You need to be sure that the base is "base".
If you look at "here" as the input and "there" as the output,
you have an IPO model, a high-level data flow. That model
decomposes into a set of interconnected paths of lower-level
IPOs. Within that decomposition is at least one set that has
the minimal number of IPOs. From that set, which possibly has
only one member, you make your choice of architecture.
Now I happen to love dataflows (analysis) and structure
charts (design) because they have a well-tested heuristic for
translating from one to the other for some 30+ years now.
There's only two forms to consider as opposed to the
somewhat indefinite, but definitely much higher, number in
UML.
Besides it's less confusing because it provides a "true" data
mapping from "here" to "there" through all the
interconnecting paths. Such a mapping tells you when you
have a "complete" solution, one without any surprises once
underway. It offers "all" participants the same picture.
It begins with data and it ends with data. The processes are
simply conduits to connect the data. That's why we call it
data processing.<g> That says you begin with the aggregate
data of the OS/2 APIs, map them to the APIs, and continue
downward until you can account for all their sources. At that
point you will have a complete picture of your kernel...and of
the organization of your documentation.
It occurs to me that at one time I created such a list of OS/2
API data by compiling a PL/I procedure consisting of all the
API entry definitions. The compiler produced an attribute and
cross-reference listing in alphabetical order of the API names
and data names as well as which APIs contained a reference
to the data name. It never occurred to me to do it in C or
C++, but I assume you can.
That's probably where I would start in the documentation:
with the end product and work backward from there to the
base level while minimizing the number of paths and
connections along the way. That will tell you when you are
done with where to "cut" it, to decompose it into separate
units to support parallel development.
That lets you plug and play the various uK API sets to find
one that meets your needs.
Date: Mon Aug 18, 2003 7:02 pm
Subject: Re: Re: Building an OS/2 Replacement lynnmaxson
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
Ben Ravago writes:
"With regards to a microkernel implementation, I'd like to
again point out the L4KA project (www.l4ka.org). There's
recently been a number of new developments here (e.g., a
Linux device driver environment) and the mailing lists seem to
indicate that people are working on interesting projects."
I took a look at both the L4KA and REACTOS projects. Earlier
I had a go at the MACH, the uK used as the basis for IBM's OS/2
for the PowerPC. I guess the questions that dwell in the back
of my mind lies in the meaning of "base APIs" for use in higher
level ones: in what ways do they differ and what is the
significance of the differences? In short why are they not
identical?
I'm not an object-oriented fan. As a result reading that
something is written almost entirely in C++ amounts to a
turnoff. I might as well admit I'm not a C fan either, having
some nearly 40 years experience with PL/I never needing to
resort to anything else regardless of the application...except
for OS/2 device drivers.<g>
The point is that you are engaged in documenting
specifications of a project prior to implementing it. Your only
problem is having some agreement with respect to the
sufficiency of the documentation at which point you can begin
the implementation. There are some who want to start it
"now" while there are others for whom "tomorrow" never
comes.
In all this you have to have a starting point "here", a base
layer API to get to a known ending point "there", the OS/2 API
layer. You know one, the OS/2 API layer. It is well
documented. You have to decide, i.e. know, eventually the
other, which you have to document. Then you have to
document how you get from "here" to "there": you have to
provide a "map". You have a mapping operation to document.
Only one of the suggested uKs has actually been used in the
production of OS/2, the MACH uK. I would suggest it as a
starting point without at the same time downgrading any of
the others. You need to be sure that the base is "base".
If you look at "here" as the input and "there" as the output,
you have an IPO model, a high-level data flow. That model
decomposes into a set of interconnected paths of lower-level
IPOs. Within that decomposition is at least one set that has
the minimal number of IPOs. From that set, which possibly has
only one member, you make your choice of architecture.
Now I happen to love dataflows (analysis) and structure
charts (design) because they have a well-tested heuristic for
translating from one to the other for some 30+ years now.
There's only two forms to consider as opposed to the
somewhat indefinite, but definitely much higher, number in
UML.
Besides it's less confusing because it provides a "true" data
mapping from "here" to "there" through all the
interconnecting paths. Such a mapping tells you when you
have a "complete" solution, one without any surprises once
underway. It offers "all" participants the same picture.
It begins with data and it ends with data. The processes are
simply conduits to connect the data. That's why we call it
data processing.<g> That says you begin with the aggregate
data of the OS/2 APIs, map them to the APIs, and continue
downward until you can account for all their sources. At that
point you will have a complete picture of your kernel...and of
the organization of your documentation.
It occurs to me that at one time I created such a list of OS/2
API data by compiling a PL/I procedure consisting of all the
API entry definitions. The compiler produced an attribute and
cross-reference listing in alphabetical order of the API names
and data names as well as which APIs contained a reference
to the data name. It never occurred to me to do it in C or
C++, but I assume you can.
That's probably where I would start in the documentation:
with the end product and work backward from there to the
base level while minimizing the number of paths and
connections along the way. That will tell you when you are
done with where to "cut" it, to decompose it into separate
units to support parallel development.
That lets you plug and play the various uK API sets to find
one that meets your needs.
Re: Part 25
#727 From: Ben Ravago <ben.ravago@...>
Date: Mon Aug 18, 2003 8:02 pm
Subject: Re: Re: Building an OS/2 Replacement ben_ravago
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
"Lynn H. Maxson" wrote:
> It begins with data and it ends with data. The processes are
> simply conduits to connect the data. That's why we call it
> data processing.<g> That says you begin with the aggregate
> data of the OS/2 APIs, map them to the APIs, and continue
> downward until you can account for all their sources. At that
> point you will have a complete picture of your kernel...and of
> the organization of your documentation.
I think comparisons between OS's like ReactOS and L4 or Mach are not quite
appropriate. ReactOS is what I would call a 'minimal' kernel; it's trying to
provide
a minimal but complete set of OS services such as paging, IO, device driver and
file driver environments, etc. One can then layer userland API's such as OS/2's
CP/PM/GPI set on top. (The OpenBEOS project is taking a similar course with
NewOS).
L4 and Mach don't even try to address these services. They concern themselves
with the basic plumbing needed to integrate these services. Typically, this
means
simply IPC and some hardware abstractions. The OS services are themselves
provided by 'servers' that are not themselves part of the microkernel
specification.
If you want to start by mapping IPO type API's then what you may want to
consider
is something like the Flux OSKit api's as a base. The OSKit provides a base of
OS
type services which can be used to construct OS 'personalities' (as the OS/2
PPC
project called them) such as OS/2, Win32 or Posix. The OSKit has been applied
to
both Mach and L4 bases. I think the GNU Hurd project uses this.
Date: Mon Aug 18, 2003 8:02 pm
Subject: Re: Re: Building an OS/2 Replacement ben_ravago
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
"Lynn H. Maxson" wrote:
> It begins with data and it ends with data. The processes are
> simply conduits to connect the data. That's why we call it
> data processing.<g> That says you begin with the aggregate
> data of the OS/2 APIs, map them to the APIs, and continue
> downward until you can account for all their sources. At that
> point you will have a complete picture of your kernel...and of
> the organization of your documentation.
I think comparisons between OS's like ReactOS and L4 or Mach are not quite
appropriate. ReactOS is what I would call a 'minimal' kernel; it's trying to
provide
a minimal but complete set of OS services such as paging, IO, device driver and
file driver environments, etc. One can then layer userland API's such as OS/2's
CP/PM/GPI set on top. (The OpenBEOS project is taking a similar course with
NewOS).
L4 and Mach don't even try to address these services. They concern themselves
with the basic plumbing needed to integrate these services. Typically, this
means
simply IPC and some hardware abstractions. The OS services are themselves
provided by 'servers' that are not themselves part of the microkernel
specification.
If you want to start by mapping IPO type API's then what you may want to
consider
is something like the Flux OSKit api's as a base. The OSKit provides a base of
OS
type services which can be used to construct OS 'personalities' (as the OS/2
PPC
project called them) such as OS/2, Win32 or Posix. The OSKit has been applied
to
both Mach and L4 bases. I think the GNU Hurd project uses this.
Re: Part 25
#728 From: "Tom Lee Mullins" <tomleem@...>
Date: Tue Aug 19, 2003 2:13 am
Subject: Re: An E-Mail to IBM? bigwarpguy
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
--- In osFree@yahoogroups.com, "Tom Lee Mullins" <tomleem@a...> wrote:
> 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
I am/was hoping that IBM would support this open source project
like they do with Linux and other open source projects they say
they said they did (with this open source project, little chance
of a lawsuit from SCO ).
BigWarpGuy
Date: Tue Aug 19, 2003 2:13 am
Subject: Re: An E-Mail to IBM? bigwarpguy
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
--- In osFree@yahoogroups.com, "Tom Lee Mullins" <tomleem@a...> wrote:
> 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
I am/was hoping that IBM would support this open source project
like they do with Linux and other open source projects they say
they said they did (with this open source project, little chance
of a lawsuit from SCO ).
BigWarpGuy
Re: Part 25
#729 From: "Lynn H. Maxson" <lmaxson@...>
Date: Tue Aug 19, 2003 3:44 am
Subject: Re: Re: Building an OS/2 Replacement lynnmaxson
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
Ben Ravago writes:
"I think comparisons between OS's like ReactOS and L4 or
Mach are not quite appropriate. ReactOS is what I would call
a 'minimal' kernel; it's trying to provide a minimal but complete
set of OS services such as paging, IO, device driver and
file driver environments, etc. One can then layer userland
API's such as OS/2's CP/PM/GPI set on top. (The OpenBEOS
project is taking a similar course with NewOS). ..."
I really wasn't comparing them. I respect the work that
occurs in academic institutions. Sometimes, however, their
work does not transfer into a commercial environment with
the extra requirements, not all technical, that becomes part of
the equation. At least with respect to this effort IBM itself
had produced a product, but released it incomplete in terms of
necessary components, e.g. an Intel emulator to execute
existing OS/2 applications.
To me it's a matter of logic. Of all the functions needed to
make an OS some are basic: their existence is required by
others. For competing OSes with the same functions they
have the same set of basic functions in common. This basic
set forms the microkernel (uK).
Now while some have produced a single operating system on a
uK base talk of multiple OSes executing concurrently on the
same uK base remains that: talk. It remains a difference
between what represents "reality" in the academic world and
that of the commercial world. So the concurrent execution
remains theoretical possibility, but not a proven one.
Nevertheless, assuming that a core set of functions exist,
anyone caring to write an OS wants an optimal set. That
optimal set more closely matches the needs of the OS's API
layer than any other. Basically then the core API set,
represented by the uK, gets driven by that of the OS's API set.
Now to offer a "complete" replacement for any kernel you
have to offer a complete replacement in every sense for its
logical interface, its API. You gain nothing by saying possibly
that some are never used and others little used. To even
know this you would have to examine every application ever
written for the OS. Determining that is more work than simply
supplying the questionable APIs.
If you are going to begin the documentation, the easiest place
to begin is with the APIs. All the APIs are documented in the
existing OS/2 Toolkit (Version 4.5), which also contains their
source form in .h files. It will probably take several iterations
to get them all "included" in a compile due to the settings of
macro "defines" which by default bypasses their inclusion.
You have to get all these switches "define"s set correctly.
You end up with a compiler listing of names: the names of the
APIs, the names of their parameters, and the names of
"values". As you go through them you will run into instances
of synonyms (different names for the same thing) and
homonyms (same name for different things). You need to
eliminate both: synonyms because only one name should be
used to avoid confusion and homonyms to insure that one
name is different from another.
Perhaps the best example of homonyms is the "rc" for return
code associated with each API. They differ in terms of the
sets of return values associated with each and in terms of the
meaning associated with each value (also a homonym
problem). The simplest means of doing this consists of
appended an index value to the name, e.g. rc0001, rc0002, etc..
When you get this far you are now ready to incorporate the
"rules" that determine the input and output values of each
name. Somewhere in getting to this point you will start to see
"patterns of use", some which form an independent though
connected set of APIs and some which overlap in part with
one or more other sets.
You are now in a position to make your "cuts", the
decomposition that supports a division of labor enabling
parallel development. As each division formulates its minimal
set of intervening layers down to the base API layer, once all
have done so they can define the APIs of this layer. This then
creates yet another division of labor, the writing of the uK
itself. The other uKs then simply get used as "reference"
documents.
What separates this from WINE and ODIN is that there is no
underlying "reality" which can in some way compromise the
reality we want to create. Because we have no code base to
maintain initially and we come into this "after the fact" of
OS/2's existence and we have no underlying reality to contend
with, we can design and produce an "optimal" solution at
reasonable cost. Neither IBM nor Microsoft with a huge source
base can afford to do it at our costs. It's the same reason
that third world countries can have more advanced
telecommunication systems than "advanced" countries: they
don't have to carry the baggage of an existing system.
Basically I've just presented how I would go about
documenting an OS/2 kernel replacement. I would say that
one person could do it in a reasonable time period. Two to
three could bring that down somewhat. More than that at
some point an increasing number will increase the time
necessary. So it isn't the number you need to focus on, as a
low number, five or less, is probably optimal. It's the skill
level of the number you have.
It's not rocket science, but attention to clerical detail, the
detail involved in insuring the connected path from the entry
of a particular piece of data to its exit as well as the rules
governing the processes encountered in that path. Thus it's a
skill you can develop.
If you are a C, C++, C#, or JAVA person, someone locked into
the paradigms of third generation languages, then it won't
occur to you that if you have the names, their layers, i.e.
hierarchical relationship, and the rules governing their
processes, i.e. transformations, you have an ideal application
to address with logic programming. What do you think it
means in terms of effort for initial development and then
ongoing maintenance to be able to input an unordered set of
data and rules and have the software contruct an optimal OS
solution, i.e. kernel, for you.<g> If you have that, then it only
takes a handful of people, not dozens, hundreds, or thousands
to successfully continue it on into the future.
Don't get too down on me when I shy away from solutions
based on either C or C++. If you are an academic, ongoing
maintenance costs are not a problem. In the real world,
however, they have driven more vendors from the
marketplace than any other cause. It does little good to have
one stage successfully implement a product with few people,
if you cannot continue it in the following stages.
It's very difficult to get a client to think beyond an immediate
problem even knowing its solution will lead yet to another.
The solution to that may mean tossing out in part or whole
the previous solution. That means if you bothered to look
ahead two, three, four or more solutions forward, you could
make decisions based on least overall effort. When you have
limited numbers to begin with you really don't have a lot of
effort to "waste".
Date: Tue Aug 19, 2003 3:44 am
Subject: Re: Re: Building an OS/2 Replacement lynnmaxson
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
Ben Ravago writes:
"I think comparisons between OS's like ReactOS and L4 or
Mach are not quite appropriate. ReactOS is what I would call
a 'minimal' kernel; it's trying to provide a minimal but complete
set of OS services such as paging, IO, device driver and
file driver environments, etc. One can then layer userland
API's such as OS/2's CP/PM/GPI set on top. (The OpenBEOS
project is taking a similar course with NewOS). ..."
I really wasn't comparing them. I respect the work that
occurs in academic institutions. Sometimes, however, their
work does not transfer into a commercial environment with
the extra requirements, not all technical, that becomes part of
the equation. At least with respect to this effort IBM itself
had produced a product, but released it incomplete in terms of
necessary components, e.g. an Intel emulator to execute
existing OS/2 applications.
To me it's a matter of logic. Of all the functions needed to
make an OS some are basic: their existence is required by
others. For competing OSes with the same functions they
have the same set of basic functions in common. This basic
set forms the microkernel (uK).
Now while some have produced a single operating system on a
uK base talk of multiple OSes executing concurrently on the
same uK base remains that: talk. It remains a difference
between what represents "reality" in the academic world and
that of the commercial world. So the concurrent execution
remains theoretical possibility, but not a proven one.
Nevertheless, assuming that a core set of functions exist,
anyone caring to write an OS wants an optimal set. That
optimal set more closely matches the needs of the OS's API
layer than any other. Basically then the core API set,
represented by the uK, gets driven by that of the OS's API set.
Now to offer a "complete" replacement for any kernel you
have to offer a complete replacement in every sense for its
logical interface, its API. You gain nothing by saying possibly
that some are never used and others little used. To even
know this you would have to examine every application ever
written for the OS. Determining that is more work than simply
supplying the questionable APIs.
If you are going to begin the documentation, the easiest place
to begin is with the APIs. All the APIs are documented in the
existing OS/2 Toolkit (Version 4.5), which also contains their
source form in .h files. It will probably take several iterations
to get them all "included" in a compile due to the settings of
macro "defines" which by default bypasses their inclusion.
You have to get all these switches "define"s set correctly.
You end up with a compiler listing of names: the names of the
APIs, the names of their parameters, and the names of
"values". As you go through them you will run into instances
of synonyms (different names for the same thing) and
homonyms (same name for different things). You need to
eliminate both: synonyms because only one name should be
used to avoid confusion and homonyms to insure that one
name is different from another.
Perhaps the best example of homonyms is the "rc" for return
code associated with each API. They differ in terms of the
sets of return values associated with each and in terms of the
meaning associated with each value (also a homonym
problem). The simplest means of doing this consists of
appended an index value to the name, e.g. rc0001, rc0002, etc..
When you get this far you are now ready to incorporate the
"rules" that determine the input and output values of each
name. Somewhere in getting to this point you will start to see
"patterns of use", some which form an independent though
connected set of APIs and some which overlap in part with
one or more other sets.
You are now in a position to make your "cuts", the
decomposition that supports a division of labor enabling
parallel development. As each division formulates its minimal
set of intervening layers down to the base API layer, once all
have done so they can define the APIs of this layer. This then
creates yet another division of labor, the writing of the uK
itself. The other uKs then simply get used as "reference"
documents.
What separates this from WINE and ODIN is that there is no
underlying "reality" which can in some way compromise the
reality we want to create. Because we have no code base to
maintain initially and we come into this "after the fact" of
OS/2's existence and we have no underlying reality to contend
with, we can design and produce an "optimal" solution at
reasonable cost. Neither IBM nor Microsoft with a huge source
base can afford to do it at our costs. It's the same reason
that third world countries can have more advanced
telecommunication systems than "advanced" countries: they
don't have to carry the baggage of an existing system.
Basically I've just presented how I would go about
documenting an OS/2 kernel replacement. I would say that
one person could do it in a reasonable time period. Two to
three could bring that down somewhat. More than that at
some point an increasing number will increase the time
necessary. So it isn't the number you need to focus on, as a
low number, five or less, is probably optimal. It's the skill
level of the number you have.
It's not rocket science, but attention to clerical detail, the
detail involved in insuring the connected path from the entry
of a particular piece of data to its exit as well as the rules
governing the processes encountered in that path. Thus it's a
skill you can develop.
If you are a C, C++, C#, or JAVA person, someone locked into
the paradigms of third generation languages, then it won't
occur to you that if you have the names, their layers, i.e.
hierarchical relationship, and the rules governing their
processes, i.e. transformations, you have an ideal application
to address with logic programming. What do you think it
means in terms of effort for initial development and then
ongoing maintenance to be able to input an unordered set of
data and rules and have the software contruct an optimal OS
solution, i.e. kernel, for you.<g> If you have that, then it only
takes a handful of people, not dozens, hundreds, or thousands
to successfully continue it on into the future.
Don't get too down on me when I shy away from solutions
based on either C or C++. If you are an academic, ongoing
maintenance costs are not a problem. In the real world,
however, they have driven more vendors from the
marketplace than any other cause. It does little good to have
one stage successfully implement a product with few people,
if you cannot continue it in the following stages.
It's very difficult to get a client to think beyond an immediate
problem even knowing its solution will lead yet to another.
The solution to that may mean tossing out in part or whole
the previous solution. That means if you bothered to look
ahead two, three, four or more solutions forward, you could
make decisions based on least overall effort. When you have
limited numbers to begin with you really don't have a lot of
effort to "waste".
Re: Part 25
#730 From: "Lynn H. Maxson" <lmaxson@...>
Date: Tue Aug 19, 2003 4:00 am
Subject: Re: Re: An E-Mail to IBM? lynnmaxson
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
Tom Lee Mullins writes:
"I am/was hoping that IBM would support this open source
project like they do with Linux and other open source projects
they say they said they did (with this open source project,
little chance of a lawsuit from SCO )."
I speak as a "retired" IBMer after 36 years as an employee.
IBM is a business, not a charity. If it supports open source
projects like Linux, it does so because an opportunity for
profit exists. If it doesn't support a particular open source
project like this one, it doesn't because an opportunity for
profit doesn't exist. It certainly doesn't want to support a
non-profitable project, open source or not, if it competes with
one in which it does profit.
IBM global services makes a profit on closed source (Windows)
and open source (Linux). If either ceased to remain profitable
it would cease offering support. That's what happened to
OS/2. Except in that instance it absorbed a billion dollars a
year in losses over several years. To the profitable
businesses in IBM who had to cover those losses from their
profits and thus reduce their investments in their own future it
didn't make sense.
IBM is not an enemy. There are probably things we could
propose successfully. We would make a better case if we had
a business case profitable to both parties than one in which
we came begging for charity. For instance, the SmallTalk
group at IBM offers OS/2 users the ability to download the
latest enterprise level version of their product for free for
non-commercial use for an unlimited trial period. If we could
get them to retrofit other dropped OS/2 products like PL/I and
APL in like manner, you would have a chance to experience
the prevalent myths with respect to C and its derivatives.
Date: Tue Aug 19, 2003 4:00 am
Subject: Re: Re: An E-Mail to IBM? lynnmaxson
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
Tom Lee Mullins writes:
"I am/was hoping that IBM would support this open source
project like they do with Linux and other open source projects
they say they said they did (with this open source project,
little chance of a lawsuit from SCO )."
I speak as a "retired" IBMer after 36 years as an employee.
IBM is a business, not a charity. If it supports open source
projects like Linux, it does so because an opportunity for
profit exists. If it doesn't support a particular open source
project like this one, it doesn't because an opportunity for
profit doesn't exist. It certainly doesn't want to support a
non-profitable project, open source or not, if it competes with
one in which it does profit.
IBM global services makes a profit on closed source (Windows)
and open source (Linux). If either ceased to remain profitable
it would cease offering support. That's what happened to
OS/2. Except in that instance it absorbed a billion dollars a
year in losses over several years. To the profitable
businesses in IBM who had to cover those losses from their
profits and thus reduce their investments in their own future it
didn't make sense.
IBM is not an enemy. There are probably things we could
propose successfully. We would make a better case if we had
a business case profitable to both parties than one in which
we came begging for charity. For instance, the SmallTalk
group at IBM offers OS/2 users the ability to download the
latest enterprise level version of their product for free for
non-commercial use for an unlimited trial period. If we could
get them to retrofit other dropped OS/2 products like PL/I and
APL in like manner, you would have a chance to experience
the prevalent myths with respect to C and its derivatives.
Re: Part 25
#731 From: Ben Ravago <ben.ravago@...>
Date: Tue Aug 19, 2003 4:15 am
Subject: Re: Re: Building an OS/2 Replacement ben_ravago
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
"Lynn H. Maxson" wrote:
> So it isn't the number you need to focus on, as a
> low number, five or less, is probably optimal. It's the skill
> level of the number you have.
This, I absolutely agree with. No amount of hard work can substiture for smart
work.
Date: Tue Aug 19, 2003 4:15 am
Subject: Re: Re: Building an OS/2 Replacement ben_ravago
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
"Lynn H. Maxson" wrote:
> So it isn't the number you need to focus on, as a
> low number, five or less, is probably optimal. It's the skill
> level of the number you have.
This, I absolutely agree with. No amount of hard work can substiture for smart
work.
Re: Part 25
#732 From: "kidmarc_arcor" <kidmarc@...>
Date: Tue Aug 19, 2003 4:59 am
Subject: Re: An E-Mail to IBM? kidmarc_arcor
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
--- In osFree@yahoogroups.com, "Lynn H. Maxson" <lmaxson@p...> wrote:
>
> IBM is not an enemy. There are probably things we could
> propose successfully. We would make a better case if we had
> a business case profitable to both parties than one in which
> we came begging for charity. For instance, the SmallTalk
> group at IBM offers OS/2 users the ability to download the
> latest enterprise level version of their product for free for
> non-commercial use for an unlimited trial period. If we could
> get them to retrofit other dropped OS/2 products like PL/I and
> APL in like manner, you would have a chance to experience
> the prevalent myths with respect to C and its derivatives.
Hello Lynn,
I had thought similar. [release of dropped OS/2 products...] IBM via
Lotus had offered VA PL/I Enterprise 2.1 for a song (14.95 USD), media
only - no manuals/support, for a brief period. It was withdrawn with
the EOL/EOS announcement of products for OS/2 and OS/2 itself
(movement to Passport Advantage).
I suspect an opportunity (foot in the door) may lie with Serenity
Systems at this point. Although the trial version [limited - time
bombed] is still available for download - ftp.
Peace
marcus
PS OT: For your flowers... try: http://www.azomite.com/
Date: Tue Aug 19, 2003 4:59 am
Subject: Re: An E-Mail to IBM? kidmarc_arcor
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
--- In osFree@yahoogroups.com, "Lynn H. Maxson" <lmaxson@p...> wrote:
>
> IBM is not an enemy. There are probably things we could
> propose successfully. We would make a better case if we had
> a business case profitable to both parties than one in which
> we came begging for charity. For instance, the SmallTalk
> group at IBM offers OS/2 users the ability to download the
> latest enterprise level version of their product for free for
> non-commercial use for an unlimited trial period. If we could
> get them to retrofit other dropped OS/2 products like PL/I and
> APL in like manner, you would have a chance to experience
> the prevalent myths with respect to C and its derivatives.
Hello Lynn,
I had thought similar. [release of dropped OS/2 products...] IBM via
Lotus had offered VA PL/I Enterprise 2.1 for a song (14.95 USD), media
only - no manuals/support, for a brief period. It was withdrawn with
the EOL/EOS announcement of products for OS/2 and OS/2 itself
(movement to Passport Advantage).
I suspect an opportunity (foot in the door) may lie with Serenity
Systems at this point. Although the trial version [limited - time
bombed] is still available for download - ftp.
Peace
marcus
PS OT: For your flowers... try: http://www.azomite.com/
Re: Part 25
#733 From: "Lynn H. Maxson" <lmaxson@...>
Date: Tue Aug 19, 2003 6:24 am
Subject: Re: Re: An E-Mail to IBM? lynnmaxson
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
marcus writes:
"I had thought similar. [release of dropped OS/2 products...]
IBM via Lotus had offered VA PL/I Enterprise 2.1 for a song
(14.95 USD), media only - no manuals/support, for a brief
period. ..."
Last Saturday at the SCOUG meeting I did a presentation on
PL/I followed by one on device drivers where I offered a PL/I
structure definition of the device header. I do these little
things when people make chance remarks quoted from other
sources about how much closer C is to assembly language
than anyone else. It's interesting to point out that a language
which actually has bit strings as a native data type is a damn
sight closer and clearer than one which doesn't.
I think IBM went overboard. They not only dropped
"download only" OS/2 products, but they also deleted all the
CSDs for them as well. It's one thing to "stabilize" a product
in terms of no further support. It's something else to drop all
the support already paid for and available up to that point. It
can't be a matter of disk space or access cost. I've not known
IBM to act out of spite. It's just that sometimes they let the
inmates run the asylum with illogical results.
I'm working on a synthesis of LISP, APL, and PL/I to create a
"universal" specification language. I pick those three, because
among them they contain more than what's available in all the
other programming languages put together. I upgrade these
third generation languages with fourth generation capabilities:
logic programming with predicate logic.
Fortunately I have PL/I for OS/2 and no longer need support
from IBM. Unfortunately I have only a few additional use
licenses to provide copies to others. The same situation exists
for the APL users in our group.
I intend to approach IBM through the two language groups,
PL/I and APL, to see if we cannot return to a previous state
of no support but with downloadable product as well as CSDs.
Date: Tue Aug 19, 2003 6:24 am
Subject: Re: Re: An E-Mail to IBM? lynnmaxson
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
marcus writes:
"I had thought similar. [release of dropped OS/2 products...]
IBM via Lotus had offered VA PL/I Enterprise 2.1 for a song
(14.95 USD), media only - no manuals/support, for a brief
period. ..."
Last Saturday at the SCOUG meeting I did a presentation on
PL/I followed by one on device drivers where I offered a PL/I
structure definition of the device header. I do these little
things when people make chance remarks quoted from other
sources about how much closer C is to assembly language
than anyone else. It's interesting to point out that a language
which actually has bit strings as a native data type is a damn
sight closer and clearer than one which doesn't.
I think IBM went overboard. They not only dropped
"download only" OS/2 products, but they also deleted all the
CSDs for them as well. It's one thing to "stabilize" a product
in terms of no further support. It's something else to drop all
the support already paid for and available up to that point. It
can't be a matter of disk space or access cost. I've not known
IBM to act out of spite. It's just that sometimes they let the
inmates run the asylum with illogical results.
I'm working on a synthesis of LISP, APL, and PL/I to create a
"universal" specification language. I pick those three, because
among them they contain more than what's available in all the
other programming languages put together. I upgrade these
third generation languages with fourth generation capabilities:
logic programming with predicate logic.
Fortunately I have PL/I for OS/2 and no longer need support
from IBM. Unfortunately I have only a few additional use
licenses to provide copies to others. The same situation exists
for the APL users in our group.
I intend to approach IBM through the two language groups,
PL/I and APL, to see if we cannot return to a previous state
of no support but with downloadable product as well as CSDs.
Re: Part 25
#734 From: "Lynn H. Maxson" <lmaxson@...>
Date: Tue Aug 19, 2003 6:30 am
Subject: Re: Re: Building an OS/2 Replacement lynnmaxson
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
Ben Ravago writes:
"This, I absolutely agree with. No amount of hard work can
substiture(sic) for smart work."
I've laid out how I would go about it in the same message. If
those responsible for documentation have an interest in
pursuing it, I would assist them in the data collection and
organization. I'm just not in the mood either to have to follow
multiple mailing lists, unnecessarily restricting content from its
interconnections.
Date: Tue Aug 19, 2003 6:30 am
Subject: Re: Re: Building an OS/2 Replacement lynnmaxson
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
Ben Ravago writes:
"This, I absolutely agree with. No amount of hard work can
substiture(sic) for smart work."
I've laid out how I would go about it in the same message. If
those responsible for documentation have an interest in
pursuing it, I would assist them in the data collection and
organization. I'm just not in the mood either to have to follow
multiple mailing lists, unnecessarily restricting content from its
interconnections.