Part 48 - Sep 11 2008

Old messages from osFree mailing list hosted by Yahoo!
admin
Site Admin
Posts: 1925
Joined: Wed Dec 19, 2018 9:23 am
firstname: osFree
lastname: admin

Part 48 - Sep 11 2008

Post by admin »

#2018 Re: [osFree] Re: New moderators.
Expand Messages

Allan Holm
Sep 11, 2008
On Wed, 10 Sep 2008 12:15:39 -0700, Lynn H. Maxson wrote:

> From other lists which I moderate I prefer to control it at the
>subscribe level on notification from Yahoo.

Well, I once tried to subscribe to the fat32 group, but got
rejected - and it wasn't really my plan to spam it ;-)

Don't you think it is actually easier to identify spammers
from the first real msg to the list ?

(I don't really expect to see much newcommers here anyway )

Allan.

Allan Holm Operating -_-_\ \ / / ____ _____ _____
Running OS/2 at _-_ _-_-_\ \/\/ /-/ -_ \ \ -_ \_ \ -__\
Unleash 32-bit power! - -_-_-_\_/\_/ -\_\ \_\ \_\ \_\ \_\ speed
alh@...
admin
Site Admin
Posts: 1925
Joined: Wed Dec 19, 2018 9:23 am
firstname: osFree
lastname: admin

Re: [osFree] Re: New moderators.

Post by admin »

#2019 Re: [osFree] Re: New moderators.
Expand Messages

Lynn H. Maxson
Sep 11, 2008
Well, I can't disagree with shooting the messenger if you don't like the
message in this instance. So far the votes have landed up in favor of
your view. I would say, "Go with it".
admin
Site Admin
Posts: 1925
Joined: Wed Dec 19, 2018 9:23 am
firstname: osFree
lastname: admin

Re: [osFree] Re: New moderators.

Post by admin »

#2020 Re: [osFree] Re: New moderators.
Expand Messages

Allan Holm
Sep 12, 2008
On Thu, 11 Sep 2008 07:37:02 -0700, Lynn H. Maxson wrote:

>Well, I can't disagree with shooting the messenger if you don't like the
>message in this instance. So far the votes have landed up in favor of
>your view. I would say, "Go with it".

OK, changed it, so new members gets moderated.
We can always change it again, if it turns out to
be a bad choice :-)

Hope everybody is happy now !


Allan.


Allan Holm Operating -_-_\ \ / / ____ _____ _____
Running OS/2 at _-_ _-_-_\ \/\/ /-/ -_ \ \ -_ \_ \ -__\
Unleash 32-bit power! - -_-_-_\_/\_/ -\_\ \_\ \_\ \_\ \_\ speed
alh@...
admin
Site Admin
Posts: 1925
Joined: Wed Dec 19, 2018 9:23 am
firstname: osFree
lastname: admin

A new year review

Post by admin »

#2021 A new year review
Expand Messages

Lynn H. Maxson
Feb 1, 2009
My recent activity on this list lies in rejecting spam from a non-member
who seems to have infected other lists more successfully. Along with
that we have had new subscribers to this essentially dormant list.
SCOUG (Southern California OS/2 User Group) has had to relocate its
server, causing several weeks outage. Apparently the same either has or
will occur with the VOICE server which serves their lists.

We have apparently several "free" OSes available and some progressively
less so in Lunix and eCS distributions which incorporate an OS
"packaging" well beyond the boundaries of its OS base. More and more
these packages rely on open source support for internet support as in
Seamonkey, Thunderbird, Firefox and OpenOffice. For the OS/2 user at
least the delay for updated versions to gain parity seems to increase.
This relates to two factors in the OS/2 community: one, its overall
population in decline and, two, its overall sub-population of developers.

Thus to me today as it was 10 years ago at Warpstock98 in Chicago where
I presented the Warpicity Proposal the issue lay in overcoming the OS
"package" support where you had then as well as now the better OS. The
issue lay in increasing developer productivity to offset declining
numbers. The solution I proposed lay in a single "true" IDE, the
Developer's Assistant, incorporating a single source-only library
system, the Data Directory/Repository, all based on a "universal"
specification (programming) language, SL/I, a fourth-generation
enhancement of PL/I.

My focus today remains in that "tool" development which began with a
larger population under CompuServe and some years back shifted to the
scoug-programming mailing list, an offshoot of the SCOUG Programming
SIG. There we have engaged primarily in discussions of development, but
little actual development. That has changed recently.

Thus I have focused on the tools to develop and maintain an OS package
that allows a smaller open source community to compete with larger ones.
More specifically to allow the open source community in general to
overwhelm the current closed (proprietary) source in terms of
maintaining pace in enhancements.

Those of you who have remained on this list as well as those who have
more recently joined it might take this opportunity to express your
views about your interests and what you would like to see offered here.
If you are just curious, that's fine. Personally I would like to know
in order to assess what personal resources to invest in what direction here.
admin
Site Admin
Posts: 1925
Joined: Wed Dec 19, 2018 9:23 am
firstname: osFree
lastname: admin

Alive, dead or in a coma

Post by admin »

#2022 Alive, dead or in a coma
Expand Messages

Lynn H. Maxson
Sep 17, 2009
In the interval since IBM exited the PC operating system business with
OS/2 we have seen a steady decline in our population. That should come
as no surprise to anyone. After IBM's exit, specifically at Warpstock98
in Chicago several presenters offered their opinions along with the
general discussion on how best to respond to not only preserve, but
enhance OS/2.

As the last presenter at that user conference I took an entirely
different approach from the other speakers, offering the Warpicity
Proposal. It had three parts, one dealing with a formal organization
supported by the population, the staffing and an enhanced methodology.
The first two quickly drifted off into the background while the
methodology assumed center stage.

Basically the methodology consists of a single language, designated as
SL/I, a single tool, designated as "The Developer's Assistant", and a
single source-only, automated library, designated as the "Data
Directory/Repository". Now the whole purpose of this trio lay in
increasing developer productivity some 50+ times and reducing
development costs some 200 times. As neither had never occurred
previously in the history of software development anywhere near those
numbers obviously skeptics and skepticism have challenged it ever since.

Understand that I chose to address productivity and cost as the central
concerns which any minority software population would have to achieve in
order to maintain or exceed the pace of support within larger
populations. I chose to offer something different, startling so,
because it could not occur using the same tools and methodology of the
larger aupported populations. With fewer people resources to draw upon
we could not compete with larger resources on their playing field. At
this moment some 11 years later history has borne me out in spades.

All that aside some interest came about in a project to create an open
source version of OS/2. That lead to some activity on a list known as
"osfree". The discussion there split between two approaches. One
proposed to create an application layer relying on an underlying
existing operating system with a larger population, namely Linux. The
other proposed to start with a micro-kernel which supported not only
OS/2 but any of the other operating systems suitably modified. The
first group focused its efforts on the freeos list while the second
group started the osfree list. Both today lie largely dormant.

Meanwhile a still active OS/2 user group, SCOUG (Southern California
OS/2 User Group) several years back had its Programming SIG focusing on
the Warpicity proposed methodology, specifically the development of the
single tool, the Developer's Assistant(DA). Anyone who wants to follow
this development can do so by subscribing to the scoug-programming list.
You can get instructions for doing so at the website, www.scoug.com.

I assume that when a dormant or relatively inactive list gets new
subscribers that they should have an idea and options to participate, if
they so desired.

The DA is an interpreter/compiler for SL/I. It is both because an
interpreter offers the most in developer productivity, his throughput,
and a compiler offers the most in transaction productivity, its
throughput. As it operates as an interpreter that means it has a
GUI-based editor. As an interpreter and compiler share syntax and
semantic analysis, differing only in code generation, which type of code
to produce becomes a developer option.

SL/I is an HLL offering both an imperative (1st, 2nd and 3rd generation)
and a declarative (4th generation) combined programming language. As
every programming language by definition is a specification language,
SL/I becomes a "universal" specification language. As such it can
define itself, a capability which makes it self-extensible.

It can combine both imperative (assignment) and declarative (assertions)
in one as its implementation uses the "standard" two-stage proof engine
of logic programming, the completeness proof and the exhaustive
true/false proof. In short it brings to an imperative language the
self-organizing capability enjoyed by all fourth generation languages,
e.g. SQL, Prolog, AI and neural networks.

To understand this you need to remember that structured programming
relies on three forms of control structures: sequence, decision and
iteration. Each of these control structures contain statements and
possibly other control structures. Thus we have only two software
entities, statements and their assemblies (control structures). Every
statement receives a software-assigned name as does every assembly which
also has a developer-assigned name.

All this occurs within the domain of the Data
Directory/Repository(DD/R). Within it on source statements are stored
as such. All assemblies, i.e. control structures, exist as list of
statement and possibly contained assembly names.

This means in turn that only a single copy of any statement or assembly
exists in the DD/R. The only replication occurs in the use instances of
names. On top of this every source name has appended to it an index, a
binary field. This insures that every instance named remains unique
regardless of the number of homonyms (same name, different referent) and
synonyms (different name, same referent) which occur. The fact that it
does homonyms automatically means that versioning is builtin, not
optional. Moreover versioning applies to every statement, assembly and
defined data elements and aggregates (assemblies).

Two things to note now. One, this treats software as a manufacturing
system. Two, every contained instance, whether element (source, data)
or assembly is reusable. That reuse is maintained automatically by the
software. Thus reuse occurs by repeated use and not by some predefined
mothod.

The fact that each statement and control structure has a unique name
means that you now have the same programming option in use by COBOL with
its "paragraphs", named code sections. It also means that any given
high level name will in turn cause all the lower level names (statements
or assemblies) to get automatically inserted in order as a consequence
of the completeness proof. Thus all organization and reorganization,
should a logic change in the underlying structures so require it, the
software will automatically reorganize the source, again as a
consequence of the completeness proof.

Thus now the developer writes in the "small" while the software
organizes in the "large". As the small is less error prone by humans
and the large absolutely not error prone by the software, you have the
best of both worlds.

Now no system is complete without testing. We have two ways of testing,
one in which we externally generate the test data and another in which
the software automatically generates it according to data ranges we
specify. The first is use by all imperative languages, which we have
now changed with our two-stage proof engine. We now have one of the two
options in use in logic programming. We have one which operates on
pre-defined data, e.g. SQL, known as "clausal" logic. We have one which
operates on automatically generating user-defined, range-based rules,
known as "predicate" logic.

The DA and SL/I use predicate logic. Thus they offer the most complete
and easiest to define set of test data. It has the effect of
eliminating the need for either alpha or beta testing or testers.

Now the DA and SL/I will not change the amount of "original" or
"modified" source. It will reduce and in fact eliminate any manual
organization or reorganization of source as well as the generation of
test data. While it gains in productivity in other areas these two,
organizing of source and automatic test daya generation, account for the
majority of time and effort in current methods. This follows the
guiding principle of "let people do what software cannot and software
what people need not."

In short if you can achieve a 50 to 1 gain in productivity, you require
a corresponding less need in human resources. We should also note that
it reverses the result of the business software development/maintenance
equation which currently favors "build to stock", volume-based
purchasing, over "build to suit", custom software. To restate this,
volume-based producers cannot compete economically with custom-based
producers. If you consider the deeper meaning of a 50 times
productivity gain, any group larger that 5 to 7 people becomes
non-competitive.
admin
Site Admin
Posts: 1925
Joined: Wed Dec 19, 2018 9:23 am
firstname: osFree
lastname: admin

Re: [osFree] Alive, dead or in a coma

Post by admin »

#2023 Re: [osFree] Alive, dead or in a coma
Expand Messages

Yuri Prokushev
Sep 17, 2009
Lynn, actually we can talk about any language/dev.environment but is we have something to look at?

wbr,
Yuri

-------------
http://prokushev.blogspot.com/
http://www.osfree.org

2009/9/17 Lynn H. Maxson <lmaxson@...>

Hide message history



In the interval since IBM exited the PC operating system business with
OS/2 we have seen a steady decline in our population. That should come
as no surprise to anyone. After IBM's exit, specifically at Warpstock98
in Chicago several presenters offered their opinions along with the
general discussion on how best to respond to not only preserve, but
enhance OS/2.

As the last presenter at that user conference I took an entirely
different approach from the other speakers, offering the Warpicity
Proposal. It had three parts, one dealing with a formal organization
supported by the population, the staffing and an enhanced methodology.
The first two quickly drifted off into the background while the
methodology assumed center stage.

Basically the methodology consists of a single language, designated as
SL/I, a single tool, designated as "The Developer's Assistant", and a
single source-only, automated library, designated as the "Data
Directory/Repository". Now the whole purpose of this trio lay in
increasing developer productivity some 50+ times and reducing
development costs some 200 times. As neither had never occurred
previously in the history of software development anywhere near those
numbers obviously skeptics and skepticism have challenged it ever since.

Understand that I chose to address productivity and cost as the central
concerns which any minority software population would have to achieve in
order to maintain or exceed the pace of support within larger
populations. I chose to offer something different, startling so,
because it could not occur using the same tools and methodology of the
larger aupported populations. With fewer people resources to draw upon
we could not compete with larger resources on their playing field. At
this moment some 11 years later history has borne me out in spades.

All that aside some interest came about in a project to create an open
source version of OS/2. That lead to some activity on a list known as
"osfree". The discussion there split between two approaches. One
proposed to create an application layer relying on an underlying
existing operating system with a larger population, namely Linux. The
other proposed to start with a micro-kernel which supported not only
OS/2 but any of the other operating systems suitably modified. The
first group focused its efforts on the freeos list while the second
group started the osfree list. Both today lie largely dormant.

Meanwhile a still active OS/2 user group, SCOUG (Southern California
OS/2 User Group) several years back had its Programming SIG focusing on
the Warpicity proposed methodology, specifically the development of the
single tool, the Developer's Assistant(DA). Anyone who wants to follow
this development can do so by subscribing to the scoug-programming list.
You can get instructions for doing so at the website, www.scoug.com.

I assume that when a dormant or relatively inactive list gets new
subscribers that they should have an idea and options to participate, if
they so desired.

The DA is an interpreter/compiler for SL/I. It is both because an
interpreter offers the most in developer productivity, his throughput,
and a compiler offers the most in transaction productivity, its
throughput. As it operates as an interpreter that means it has a
GUI-based editor. As an interpreter and compiler share syntax and
semantic analysis, differing only in code generation, which type of code
to produce becomes a developer option.

SL/I is an HLL offering both an imperative (1st, 2nd and 3rd generation)
and a declarative (4th generation) combined programming language. As
every programming language by definition is a specification language,
SL/I becomes a "universal" specification language. As such it can
define itself, a capability which makes it self-extensible.

It can combine both imperative (assignment) and declarative (assertions)
in one as its implementation uses the "standard" two-stage proof engine
of logic programming, the completeness proof and the exhaustive
true/false proof. In short it brings to an imperative language the
self-organizing capability enjoyed by all fourth generation languages,
e.g. SQL, Prolog, AI and neural networks.

To understand this you need to remember that structured programming
relies on three forms of control structures: sequence, decision and
iteration. Each of these control structures contain statements and
possibly other control structures. Thus we have only two software
entities, statements and their assemblies (control structures). Every
statement receives a software-assigned name as does every assembly which
also has a developer-assigned name.

All this occurs within the domain of the Data
Directory/Repository(DD/R). Within it on source statements are stored
as such. All assemblies, i.e. control structures, exist as list of
statement and possibly contained assembly names.

This means in turn that only a single copy of any statement or assembly
exists in the DD/R. The only replication occurs in the use instances of
names. On top of this every source name has appended to it an index, a
binary field. This insures that every instance named remains unique
regardless of the number of homonyms (same name, different referent) and
synonyms (different name, same referent) which occur. The fact that it
does homonyms automatically means that versioning is builtin, not
optional. Moreover versioning applies to every statement, assembly and
defined data elements and aggregates (assemblies).

Two things to note now. One, this treats software as a manufacturing
system. Two, every contained instance, whether element (source, data)
or assembly is reusable. That reuse is maintained automatically by the
software. Thus reuse occurs by repeated use and not by some predefined
mothod.

The fact that each statement and control structure has a unique name
means that you now have the same programming option in use by COBOL with
its "paragraphs", named code sections. It also means that any given
high level name will in turn cause all the lower level names (statements
or assemblies) to get automatically inserted in order as a consequence
of the completeness proof. Thus all organization and reorganization,
should a logic change in the underlying structures so require it, the
software will automatically reorganize the source, again as a
consequence of the completeness proof.

Thus now the developer writes in the "small" while the software
organizes in the "large". As the small is less error prone by humans
and the large absolutely not error prone by the software, you have the
best of both worlds.

Now no system is complete without testing. We have two ways of testing,
one in which we externally generate the test data and another in which
the software automatically generates it according to data ranges we
specify. The first is use by all imperative languages, which we have
now changed with our two-stage proof engine. We now have one of the two
options in use in logic programming. We have one which operates on
pre-defined data, e.g. SQL, known as "clausal" logic. We have one which
operates on automatically generating user-defined, range-based rules,
known as "predicate" logic.

The DA and SL/I use predicate logic. Thus they offer the most complete
and easiest to define set of test data. It has the effect of
eliminating the need for either alpha or beta testing or testers.

Now the DA and SL/I will not change the amount of "original" or
"modified" source. It will reduce and in fact eliminate any manual
organization or reorganization of source as well as the generation of
test data. While it gains in productivity in other areas these two,
organizing of source and automatic test daya generation, account for the
majority of time and effort in current methods. This follows the
guiding principle of "let people do what software cannot and software
what people need not."

In short if you can achieve a 50 to 1 gain in productivity, you require
a corresponding less need in human resources. We should also note that
it reverses the result of the business software development/maintenance
equation which currently favors "build to stock", volume-based
purchasing, over "build to suit", custom software. To restate this,
volume-based producers cannot compete economically with custom-based
producers. If you consider the deeper meaning of a 50 times
productivity gain, any group larger that 5 to 7 people becomes
non-competitive.
admin
Site Admin
Posts: 1925
Joined: Wed Dec 19, 2018 9:23 am
firstname: osFree
lastname: admin

Re: [osFree] Alive, dead or in a coma

Post by admin »

#2024 Re: [osFree] Alive, dead or in a coma
Expand Messages

Lynn H. Maxson
Sep 17, 2009
Yuri,

SL/I comes as a transformation and enhancement of PL/I to incorporate
fourth generation or logic programming capabilities. In effect the
software naming of source statements and control structures within the
tool, the DA, transforms PL/I into a functional programming language
with all the capibilities of, say, Haskell.

Imperative functional programming languages and declarative fourth
generation languages rely on an internal hierarchy of invoked names
which effectively defines its structure. It could occur from a higher
level function invoking lower levels and these repeating it in turn
until reaching the lowest level...as in a functional programming
language. It could occur from a higher level assertion, i.e. goal,
invoking a lower level, i.e. sub-goal, and these in turn lower level
sub-goals until reaching the lowest sub-goal levels...as in logic
programming, e.g. Prolog.

In truth imperative HLLs like PL/I and C use procedure calls, i.e. APIs,
to do the same thing. Two, things to note. One, the smallest unit is a
procedure call, something larger than a control structure or a
statement. Thus reuse does not extend automatically below that level.
Two, PL/I and C require that developer manually organize the arrangement
of the control structures. If a change occurs requiring a change in the
structure, a manual reorganization occurs.

Now transforming PL/I or C into functional programming form by giving
all control structures names means that you can introduce them as source
in any order, that the software as part of the completeness proof
replaces the manual organization and reorganization as needed.

You may think I have avoided answering your question, but I assure you I
will not. The SCOUG Programming SIG has begun the implementation of the
single tool, the Developer's Assistant, which will grow incrementally
from a GUI editor based on the Presentation Manager. We will use IBM's
OS/2 VisualAge PL/I compiler (pick your version).

As SL/I essentially exists as an enhanced PL/I with only a few
additional attributes, the syntax remains the same. Each program
element is a statement. Every statement ends in a semi-colon. That
includes statement group delimiters like "do;" and "end;" instead of the
braces used in C.

So you might say that we begin with a working though restricted subset
of SL/I, namely PL/I, to which we will incrementally add the
enhancements to bring it to a full SL/I. That will occur as needed
within the development of the Developer's Assistant. When the one is
"operational" the other will be also.

So the first step to fully appreciate SL/I as a "universal"
specification language, meaning no other including assembly language is
ever needed, lies in acquiring an appreciation and understanding of
PL/I. Regardless you have a working language from which all the rest
will evolve without using anything else.

Our intent is to have the complete documentation, source code and
executables available from our website. That documentation will come
from the email messages on the scoug-programming list. We are not
exactly swift, but we will eventually get it started and hopefully
maintain a reasonably constant development momentum.

We do have a master programmer, Bob Blair, who like I and others in
SCOUG are retired IBMers. I came into the IT business in June of 1956
and thus have some 53 years of software experience. I've been through
my share of programming languages and operating systems, including
writing some in the early 60s.

You will always note my emphasis on improved developer productivity.
The goal lies in increasing it to the point where we can in fact
implement changes at least as fast on average as they occur. In short
to eliminate the "backlog" problem which has plagued this industry since
its beginnings. If you bother to follow this as it develops, you will
come to understand how each piece no matter how it deviates from current
practice contributes to that end.

For example, the single source library concept of the Data
Directory/Repository. First off interpreters use a source-only
approach, allowing you to execute and test a single statement, a control
structure or any hierarchical sequence of control structures extending
well beyond the current procedure boundary restriction in place
currently for source level testing and debugging.

Bear in mind that it is all open source, the operating system, all tools
and applications, all in a single library system. Thus you have
available to you a hierarchical "path" of control structures from you
initial point of execution down through all levels crossing procedure
and API boundaries to the lowest level invoked from within the operating
system.

At the source level .dll, .sys, .exe, etc. don't exist as such. Thus if
you select a path from the lowest level in the OS to the point of
invocation in your program, you can fully engage in source level
debugging and testing throughout its entirety. Couple with that the use
of the previously mention predicate logic to automatically generate the
test data you can actually determine, detect and correct an error
regardless of where it occurs in the path.

Beyond that a single source library approach makes it impossible to have
the incompatibilities that have existed in the past from having multiple
libraries, source or not. Specifically since it supports "inheritance"
differently from that of OO programming class libraries you do not have
the conflicts and incompatibilities that they created. These have led
now to "standard" class libraries. We simply begin with one to which
only "standard" can apply without creating incompatibilities across
versions as has occurred in JAVA.

I only go to the effort here tp emphasize that any package software like
OS/2 which includes far more than its kernel has a cost in human
resources well beyond that either in use or available within the OS/2
population with current tools. That cost drove IBM to drop marketing
and development of OS/2 again due to current tools. When you have a
team of 50 people working full time for 18 months to produce a CSD you
find you need three of them in order to produce a CSD every 6 months.

So my point at Warpstock98 lay in the understanding of the people cost,
the full-time people cost, involved in developing and maintaining a
software package like OS/2 using current tools and methodology. Other
presenters offer good alternatives in terms of an approach like ODIN,
but eventually unsustainable using current tools and methodology. Right
now a major application like OpenOffice on OS/2(or eCS) lags
significantly behind that available on Windows. Unless you go through a
somewhat technical process, which certainly detracts users from OS/2,
you cannot run different versions of Thunderbird, Mozilla, Firefox and
Seamonkey concurrently as you can in Windows.

Now all this was predictable, the consequences of open source
development based on volunteer efforts using current tools and methods.
I'm not in the business of using hindsight now to claim, "I told you
so." I am in the business of getting people to break out of the box to
take a different approach using existing technology to allow them to
have what they wanted to achieve back in 98.

Again I invite you at least to observe the progress of our project by
subscribing to the scoug-programming email list and taking advantage of
our website once we get out piece started. In truth you don't have to
do anything except watch. We don't need money. For the time being we
don't need any help. In truth we may never need more than we have
currently.

I should end this with another enticement. We have tossed the
unnecessary restriction that a compiler (or for that matter interpreter)
unit of work is a single program. In fact we allow an unlimited number
of programs as a single unit of work. This means that an application
system which has online transactions, daily, weekly and further
frequency processing can occur as a single unit of work. Thus when we
have made all our changes and the completeness proof has done its
organization of each program, we can compile an unlimited number of
programs concurrently. From a single developer. At a single time.
Simplifying greater the challenge of change synchronization.

In short we extend the current "package" concept of compiling multiple
external procedures into a single main procedure to allow an unlimited
number of mains to occur. If, for example, we change the internal logic
of one control structure, we can direct the Data Directory/Repository to
replace the current version in all use instances with the new version
and input all affected program source into the DA. Here we can test
each program exhaustively based on our use of predicate logic for
generating test data. When satisfied with the result order their
compilation for production.

Now do you see the importance of rethinking how our tools should work?
By the way we have no "make", "build" or "link" involved.
admin
Site Admin
Posts: 1925
Joined: Wed Dec 19, 2018 9:23 am
firstname: osFree
lastname: admin

Re: [osFree] Alive, dead or in a coma

Post by admin »

#2025 Re: [osFree] Alive, dead or in a coma
Expand Messages

Allan Holm
Oct 18, 2009
On Thu, 17 Sep 2009 14:59:55 -0500, Lynn H. Maxson wrote:

>All that aside some interest came about in a project to create an open
>source version of OS/2. That lead to some activity on a list known as
>"osfree". The discussion there split between two approaches. One
>proposed to create an application layer relying on an underlying
>existing operating system with a larger population, namely Linux. The
>other proposed to start with a micro-kernel which supported not only
>OS/2 but any of the other operating systems suitably modified. The
>first group focused its efforts on the freeos list while the second
>group started the osfree list. Both today lie largely dormant.

Well, this is not really the truth for osFree.
You are right, that this list is silent - and that is really unfortunate,
but there is actually a lot going on behind the scenes.
Sure, we need more developer here, to get things going faster - but that
is the usual problem for anything OS/2 related these days.

osFree reached version 0.0.4 a month ago. The goal for 0.0.4 was to
boot the microkernel, start the OS2 personality server, and load and
execute an os/2 LX app.
An ISO is available at the osFree.org site, showing this ( but besides
that, it is not currently useful for anything :-) )

Next steps is to start implementing all the API's for OS/2 - and again
we sure could use more people for these tasks.

As getting new OS's onto a disk without destroying any existing ones
always seems to be problem, a new 'Bootmanager' is also under development.
Apart from any existing ones, this one tries to make life easier for us.
It should be able to be installed on 'any' existing partition, and it
should make it possible to boot from flash drives, and even several
different OS's from the same partition. Not ready yet, but it is coming
along.

With the current number of developers on the project, this will however
take 100 years or more to finish - so it is time for all developers to
help us out - at least just a little bit.

Lynns suggestion for better tools are naturally a good idea too. osFree
is not currently bound to any specific language anyway - we are open for
any code, that can be compiled with available tools.


I hope this little heads up show, that osFree is very much alive :-)


Allan.





Allan Holm Operating -_-_\ \ / / ____ _____ _____
Running OS/2 at _-_ _-_-_\ \/\/ /-/ -_ \ \ -_ \_ \ -__\
Unleash 32-bit power! - -_-_-_\_/\_/ -\_\ \_\ \_\ \_\ \_\ speed
alh@...
admin
Site Admin
Posts: 1925
Joined: Wed Dec 19, 2018 9:23 am
firstname: osFree
lastname: admin

Re: [osFree] Alive, dead or in a coma

Post by admin »

#2026 Re: [osFree] Alive, dead or in a coma
Expand Messages

Lynn H. Maxson
Oct 18, 2009
"... I hope this little heads up show, that osFree is very much alive
:-)"--Alan Holm

Well, that's good news. I need to track this development. I need to
investigate the development more to know what, if anything, I can
contribute.

My own effort bogged down now in just getting PM programming embedded in
my nervous system so that I can develop the Developer's Assistant
complete as a working application plus visual tutorial. The problems
that you relate, one, the need for more developers and, two, the
debugging or testing needs lie at the core of the problem I see with
using "available" tools. That's why I took the tack of producing better
tools which increase productivity significantly(50 times) and provides
for automatic testing, the generation of test data and its execution
against the source.

Now you may not think the choice of language that significant, but then
you do not have a possible one language solution without reliance at
some point on assembly language. If you have a language, for example,
based on C's concept of a variable-length, null-terminated string,
you're going to play hell when it comes to bit strings and bit
manipulation, both of which you have as native support in PL/I. The
plain fact of the matter says in my now nearly 45 years of PL/I in
scientific, commercial and real time programming I have never had to
revert to assembly language.

More to the point you have "available" tools and my tool remains
"unavailable". That leaves me with nothing to offer you. Thus it makes
no sense until you come to a real understanding of PL/I's advantage with
"available" tools for you to change course. The burden for the proof of
the pudding lies with me. Perhaps I can contribute by transforming the
current development into PL/I and working in parallel until my tool
reaches "take off".

I understand the importance and scarcity of your time. I don't want to
offer a diversion at this moment. If you care to track my tool
development prior to our placing it on the SCOUG website (www.scoug.com)
you can subscribe to scoug-programming from the same website where the
discussion continues.

In the meantime I do wish you well with continued progress.
admin
Site Admin
Posts: 1925
Joined: Wed Dec 19, 2018 9:23 am
firstname: osFree
lastname: admin

osFree news

Post by admin »

#2027 osFree news
Expand Messages

Allan Holm
Nov 8, 2009
I think it is time for a little update,
so people don't go around thinking, this project is dead :-)

Today we fixed some of the final missing things in our new
bootmanager - and we have now successfully installed it on
FAT, FAT32, HPFS and JFS volumens.
It is a _very_ flexible bootmanager - it can be installed on
HD's as well as Flash drives, or CD's , and it boots any OS
on the mentioned filesystems - you can even have several different
OS's on same partition !

Although it works, it is still a 'tool for nerds' requirering
a lot of manual config.

It will take a little while to make it a bit more user friendly,
but we are on the way to do it :-)


Allan.

Allan Holm Operating -_-_\ \ / / ____ _____ _____
Running OS/2 at _-_ _-_-_\ \/\/ /-/ -_ \ \ -_ \_ \ -__\
Unleash 32-bit power! - -_-_-_\_/\_/ -\_\ \_\ \_\ \_\ \_\ speed
alh@...
Post Reply