#251 From: Kris Steenhaut <kris.steenhaut@...>
Date: Sat Feb 23, 2002 3:30 am
Subject: Re: Re: Unable to help: What do you need to participate ? krissteenhaut
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
drittervonfuenf schreef:
>
> Well it was legal for her to do so because the OS2LDR had
> a bug/feature which prevented it to run fully on her system.
Whatever it was, it's legal now as Big Blue didn't make any complaint.
--
Groeten uit Gent,
Kris
Part 9 - Feb 22 2002
Re: Part 9
#252 From: J Christopher Kennedy <kb7nmu@...>
Date: Sat Feb 23, 2002 4:14 am
Subject: Re: OSFree and our future kb7nmu
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
In <0GRY00E1J1CWFI@...>, on 02/22/2002
at 08:48 AM, "Lynn H. Maxson" <lmaxson@...> said:
[BIG SNIP]
>Yet we insist on the use of source files as the fundamental input units to
>a compile. These source files themselves as assemblies. None of our
>tools allows us to input or deal with source statements as raw material,
>as reusable components, only files or other assemblies. Unless we do
>treat source statements as our raw material on which we construct all
>higher level assemblies and assemblies of assemblies we will not achieve a
>"true"
>manufacturing approach.
>Source statements are reusable components. If they are, there should only
>be one copy, one instance, of every source statement in our source
>database. That copy should have a name, possibly context-based just as we
>have a name for every assembly. That means that every named assembly
>consists of the names of lower level components which may in turn consist
>of lower level
>components until we ultimately have only a set of raw material, our bill
>of material.
[BIG SNIP]
Hmm... If I am understanding you correctly, what you are describing is
FORTH, invented in 1970 by Chuck Moore. In Forth, the basic unit of reuse
is the word, not the source file. You compose a program as a word, which
references other words, etc., until you are at the base level of Forth
primitives, which are words which break down no farther.
Yep, just read the above paragraphs again, and that is what you are
describing. You should especially check out Chuck Moore's work on Minimal
Instruction Set Computing (MISC). More about Forth can be found at
http://www.forth.org/
Have a good day.
--
-----------------------------------------------------------
J Christopher Kennedy <kb7nmu@...>
http://www.dragonbard.com/
-----------------------------------------------------------
Date: Sat Feb 23, 2002 4:14 am
Subject: Re: OSFree and our future kb7nmu
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
In <0GRY00E1J1CWFI@...>, on 02/22/2002
at 08:48 AM, "Lynn H. Maxson" <lmaxson@...> said:
[BIG SNIP]
>Yet we insist on the use of source files as the fundamental input units to
>a compile. These source files themselves as assemblies. None of our
>tools allows us to input or deal with source statements as raw material,
>as reusable components, only files or other assemblies. Unless we do
>treat source statements as our raw material on which we construct all
>higher level assemblies and assemblies of assemblies we will not achieve a
>"true"
>manufacturing approach.
>Source statements are reusable components. If they are, there should only
>be one copy, one instance, of every source statement in our source
>database. That copy should have a name, possibly context-based just as we
>have a name for every assembly. That means that every named assembly
>consists of the names of lower level components which may in turn consist
>of lower level
>components until we ultimately have only a set of raw material, our bill
>of material.
[BIG SNIP]
Hmm... If I am understanding you correctly, what you are describing is
FORTH, invented in 1970 by Chuck Moore. In Forth, the basic unit of reuse
is the word, not the source file. You compose a program as a word, which
references other words, etc., until you are at the base level of Forth
primitives, which are words which break down no farther.
Yep, just read the above paragraphs again, and that is what you are
describing. You should especially check out Chuck Moore's work on Minimal
Instruction Set Computing (MISC). More about Forth can be found at
http://www.forth.org/
Have a good day.
--
-----------------------------------------------------------
J Christopher Kennedy <kb7nmu@...>
http://www.dragonbard.com/
-----------------------------------------------------------
Re: Part 9
#253 From: "cowwoc2001" <junk@...>
Date: Sat Feb 23, 2002 7:47 am
Subject: My perspective cowwoc2001
Online Now Online Now
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
Yes.. yes _another_ perspective on the legal issue. yeesh!
Basically my view is that you should do whatever you want with the
stolen source-codes (if the source-code is indeed stolen), but make
sure to never release anything based upon stolen sources to the
public. Meaning that you start off using "bad code" with no public
releases and as time goes by you rewrite more and more of the "bad
code" with your own and release that. The beauty in such a technique
is that you'll easily trace new bugs back to the source by comparing
with the original code.
Ciao,
Gili
Date: Sat Feb 23, 2002 7:47 am
Subject: My perspective cowwoc2001
Online Now Online Now
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
Yes.. yes _another_ perspective on the legal issue. yeesh!
Basically my view is that you should do whatever you want with the
stolen source-codes (if the source-code is indeed stolen), but make
sure to never release anything based upon stolen sources to the
public. Meaning that you start off using "bad code" with no public
releases and as time goes by you rewrite more and more of the "bad
code" with your own and release that. The beauty in such a technique
is that you'll easily trace new bugs back to the source by comparing
with the original code.
Ciao,
Gili
Re: Part 9
#254 From: "Bsobla Mage" <Bsobla_1523@...>
Date: Fri Feb 22, 2002 6:22 pm
Subject: Re: My perspective bsobla1715
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
Gili --
A response in reverse seems appropriate here ...
<
In addition, I wonder for your soul ! ...
the concept of 'obscurity makes security' (aka camouflage) frequently works in
the fleshy-world, but in this
(networked) age -- it's mostly useless, clever marketing notwithstanding (!).
Over time, software programs ( like fleshy-life forms ) have traits that betray
source. Witness the (multiple)
hack attacks based on OS signatures... Witness the current (US) hoo-ha about
Enron...
There are always those that archive, track and record such things, finding
the 'tells', reporting the frauds.
fundamentally, it seems to me that your technique provides little useful
feedback to your <private> source
vis-a-vis the "public" releases. Your <private> codebase will be unmanageable
from the start.
-- the 'ugly' to your "beauty": resolution of conflicting implementations
(the '(perhaps) multi-buggy' /
'legally challenged' public version vice your 'golden' version) will become
impossible.
>
Ciao !
On Sat, 23 Feb 2002 04:47:43 -0000, cowwoc2001 wrote:
>
> Yes.. yes _another_ perspective on the legal issue. yeesh!
>
> Basically my view is that you should do whatever you want with the
>stolen source-codes (if the source-code is indeed stolen), but make
>sure to never release anything based upon stolen sources to the
>public. Meaning that you start off using "bad code" with no public
>releases and as time goes by you rewrite more and more of the "bad
>code" with your own and release that. The beauty in such a technique
>is that you'll easily trace new bugs back to the source by comparing
>with the original code.
>
>Ciao,
>Gili
>
>
>To unsubscribe from this group, send an email to:
>osFree-unsubscribe@yahoogroups.com
>
>
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
Date: Fri Feb 22, 2002 6:22 pm
Subject: Re: My perspective bsobla1715
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
Gili --
A response in reverse seems appropriate here ...
<
In addition, I wonder for your soul ! ...
the concept of 'obscurity makes security' (aka camouflage) frequently works in
the fleshy-world, but in this
(networked) age -- it's mostly useless, clever marketing notwithstanding (!).
Over time, software programs ( like fleshy-life forms ) have traits that betray
source. Witness the (multiple)
hack attacks based on OS signatures... Witness the current (US) hoo-ha about
Enron...
There are always those that archive, track and record such things, finding
the 'tells', reporting the frauds.
fundamentally, it seems to me that your technique provides little useful
feedback to your <private> source
vis-a-vis the "public" releases. Your <private> codebase will be unmanageable
from the start.
-- the 'ugly' to your "beauty": resolution of conflicting implementations
(the '(perhaps) multi-buggy' /
'legally challenged' public version vice your 'golden' version) will become
impossible.
>
Ciao !
On Sat, 23 Feb 2002 04:47:43 -0000, cowwoc2001 wrote:
>
> Yes.. yes _another_ perspective on the legal issue. yeesh!
>
> Basically my view is that you should do whatever you want with the
>stolen source-codes (if the source-code is indeed stolen), but make
>sure to never release anything based upon stolen sources to the
>public. Meaning that you start off using "bad code" with no public
>releases and as time goes by you rewrite more and more of the "bad
>code" with your own and release that. The beauty in such a technique
>is that you'll easily trace new bugs back to the source by comparing
>with the original code.
>
>Ciao,
>Gili
>
>
>To unsubscribe from this group, send an email to:
>osFree-unsubscribe@yahoogroups.com
>
>
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
Re: Part 9
#255 From: "Michal Necasek" <michaln@...>
Date: Sat Feb 23, 2002 9:29 am
Subject: Re: My perspective michalnec
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
On Sat, 23 Feb 2002 04:47:43 -0000, cowwoc2001 wrote:
> Basically my view is that you should do whatever you want with the
>stolen source-codes (if the source-code is indeed stolen), but make
>sure to never release anything based upon stolen sources to the
>public. Meaning that you start off using "bad code" with no public
>releases and as time goes by you rewrite more and more of the "bad
>code" with your own and release that. The beauty in such a technique
>is that you'll easily trace new bugs back to the source by comparing
>with the original code.
>
I wonder how many people remember what Phoenix Technologies did
back in early 1980's (I don't from personal experience). They took
source listings or IBM PC ROM BIOS (perhaps disassemblies too),
those were published in the Technical Reference. One team studied
the IBM BIOS extensively and wrote a specification based on it.
Another team never saw a line of IBM code, only the specs. The
result was Phoenix BIOS, a perfectly legal clone of IBM BIOS
which basically enabled the whole PC clone market to exist. I bet
IBM wasn't very happy about it.
Michal
Date: Sat Feb 23, 2002 9:29 am
Subject: Re: My perspective michalnec
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
On Sat, 23 Feb 2002 04:47:43 -0000, cowwoc2001 wrote:
> Basically my view is that you should do whatever you want with the
>stolen source-codes (if the source-code is indeed stolen), but make
>sure to never release anything based upon stolen sources to the
>public. Meaning that you start off using "bad code" with no public
>releases and as time goes by you rewrite more and more of the "bad
>code" with your own and release that. The beauty in such a technique
>is that you'll easily trace new bugs back to the source by comparing
>with the original code.
>
I wonder how many people remember what Phoenix Technologies did
back in early 1980's (I don't from personal experience). They took
source listings or IBM PC ROM BIOS (perhaps disassemblies too),
those were published in the Technical Reference. One team studied
the IBM BIOS extensively and wrote a specification based on it.
Another team never saw a line of IBM code, only the specs. The
result was Phoenix BIOS, a perfectly legal clone of IBM BIOS
which basically enabled the whole PC clone market to exist. I bet
IBM wasn't very happy about it.
Michal
Re: Part 9
#256 From: "Michal Necasek" <michaln@...>
Date: Sat Feb 23, 2002 9:33 am
Subject: Re: My perspective michalnec
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
On Fri, 22 Feb 2002 22:22:24 +0700, Bsobla Mage wrote:
>Gili --
>
>A response in reverse seems appropriate here ...
>
><
>In addition, I wonder for your soul ! ...
>
[snip]
And I thought _I_ was expressing myself in an incomprehensible
manner!
Michal
Date: Sat Feb 23, 2002 9:33 am
Subject: Re: My perspective michalnec
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
On Fri, 22 Feb 2002 22:22:24 +0700, Bsobla Mage wrote:
>Gili --
>
>A response in reverse seems appropriate here ...
>
><
>In addition, I wonder for your soul ! ...
>
[snip]
And I thought _I_ was expressing myself in an incomprehensible
manner!
Michal
Re: Part 9
#257 From: Jason Filby <jasonfilby@...>
Date: Sat Feb 23, 2002 9:56 am
Subject: Re: NewOS jasonfilby
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
Wouldn't ReactOS -- aiming to be an NT clone -- be a better fit?
- Jason
--- JMA <mail@...> wrote:
> On Fri, 22 Feb 2002 16:46:02 +0100, criguada@... wrote:
>
> >Hi all,
> >
> >reading the OpenBeOS FAQ I found out this one:
> http://newos.sourceforge.net.
> >
> >Please, those knowledgeable in kernel coding look through it, and
> report
> >how good it would be to base an OS/2-compatible kernel upon.
> >This seems a fresh implementation, without unix heritage.
> >
> >Here are a few lines from the website:
> >
> >Implemented Features
> >
> > * Multithreaded
> > * Multiprocessor
> > * Fully reentrant kernel
> > * Protected memory
> > * Separate user and kernel space
> > * Text-based console
> > * Full locking primitives
> > * Kernel debugging support with installable debugger commands
> and
> >remote gdb support
> > * Modern VM design (demand paging, swapping, memory mapping),
> with
> >support for full filesystem cache integration
> > * Dynamically loadable kernel modules: drivers, filesystems,
> generic
> >modules
> > * Full virtual filesystem layer, device file system
> > * Initial support for iso9660 and ext2fs filesystems
> > * Full user space shared lib support
> > * Kernel based network stack (UDP/IP for now)
> > * Remote block device
> > * Basic VESA mode support with generic framebuffer console
> >
> Did a quick look at their page and it sounds quite good.
>
> PLEASE, can people with kernel knowledge download it, build it and
> so how
> well it would fit.
>
>
>
>
>
> Sincerely
>
> JMA
> Development and Consulting
>
> John Martin , jma@...
> ==================================
> Website: http://www.jma.se/
> email: mail@...
> Phone: 46-(0)70-6278410
> ==================================
>
>
>
> ------------------------ Yahoo! Groups Sponsor
>
> To unsubscribe from this group, send an email to:
> osFree-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>
>
__________________________________________________
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
http://sports.yahoo.com
Date: Sat Feb 23, 2002 9:56 am
Subject: Re: NewOS jasonfilby
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
Wouldn't ReactOS -- aiming to be an NT clone -- be a better fit?
- Jason
--- JMA <mail@...> wrote:
> On Fri, 22 Feb 2002 16:46:02 +0100, criguada@... wrote:
>
> >Hi all,
> >
> >reading the OpenBeOS FAQ I found out this one:
> http://newos.sourceforge.net.
> >
> >Please, those knowledgeable in kernel coding look through it, and
> report
> >how good it would be to base an OS/2-compatible kernel upon.
> >This seems a fresh implementation, without unix heritage.
> >
> >Here are a few lines from the website:
> >
> >Implemented Features
> >
> > * Multithreaded
> > * Multiprocessor
> > * Fully reentrant kernel
> > * Protected memory
> > * Separate user and kernel space
> > * Text-based console
> > * Full locking primitives
> > * Kernel debugging support with installable debugger commands
> and
> >remote gdb support
> > * Modern VM design (demand paging, swapping, memory mapping),
> with
> >support for full filesystem cache integration
> > * Dynamically loadable kernel modules: drivers, filesystems,
> generic
> >modules
> > * Full virtual filesystem layer, device file system
> > * Initial support for iso9660 and ext2fs filesystems
> > * Full user space shared lib support
> > * Kernel based network stack (UDP/IP for now)
> > * Remote block device
> > * Basic VESA mode support with generic framebuffer console
> >
> Did a quick look at their page and it sounds quite good.
>
> PLEASE, can people with kernel knowledge download it, build it and
> so how
> well it would fit.
>
>
>
>
>
> Sincerely
>
> JMA
> Development and Consulting
>
> John Martin , jma@...
> ==================================
> Website: http://www.jma.se/
> email: mail@...
> Phone: 46-(0)70-6278410
> ==================================
>
>
>
> ------------------------ Yahoo! Groups Sponsor
>
> To unsubscribe from this group, send an email to:
> osFree-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>
>
__________________________________________________
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
http://sports.yahoo.com
Re: Part 9
#258 From: "Bsobla Mage" <Bsobla_1523@...>
Date: Fri Feb 22, 2002 8:20 pm
Subject: Re: My perspective bsobla1715
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
So,
I don't wonder about what happened during the early days of the IBM PC, because
I remember those
days... halcyon days were they ...
Michal, I believe that your response is factually incorrect, pleasant as it is.
I suggest that all check google using "reverse engineer IBM PC" for a more
documented history and
'color'.
v/r
Don
On Fri, 22 Feb 2002 22:29:14 -0800 (PST), Michal Necasek wrote:
>On Sat, 23 Feb 2002 04:47:43 -0000, cowwoc2001 wrote:
>
>> Basically my view is that you should do whatever you want with the
>>stolen source-codes (if the source-code is indeed stolen), but make
>>sure to never release anything based upon stolen sources to the
>>public. Meaning that you start off using "bad code" with no public
>>releases and as time goes by you rewrite more and more of the "bad
>>code" with your own and release that. The beauty in such a technique
>>is that you'll easily trace new bugs back to the source by comparing
>>with the original code.
>>
> I wonder how many people remember what Phoenix Technologies did
>back in early 1980's (I don't from personal experience). They took
>source listings or IBM PC ROM BIOS (perhaps disassemblies too),
>those were published in the Technical Reference. One team studied
>the IBM BIOS extensively and wrote a specification based on it.
>Another team never saw a line of IBM code, only the specs. The
>result was Phoenix BIOS, a perfectly legal clone of IBM BIOS
>which basically enabled the whole PC clone market to exist. I bet
>IBM wasn't very happy about it.
>
>
> Michal
>
>
>
>
>To unsubscribe from this group, send an email to:
>osFree-unsubscribe@yahoogroups.com
>
>
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
Date: Fri Feb 22, 2002 8:20 pm
Subject: Re: My perspective bsobla1715
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
So,
I don't wonder about what happened during the early days of the IBM PC, because
I remember those
days... halcyon days were they ...
Michal, I believe that your response is factually incorrect, pleasant as it is.
I suggest that all check google using "reverse engineer IBM PC" for a more
documented history and
'color'.
v/r
Don
On Fri, 22 Feb 2002 22:29:14 -0800 (PST), Michal Necasek wrote:
>On Sat, 23 Feb 2002 04:47:43 -0000, cowwoc2001 wrote:
>
>> Basically my view is that you should do whatever you want with the
>>stolen source-codes (if the source-code is indeed stolen), but make
>>sure to never release anything based upon stolen sources to the
>>public. Meaning that you start off using "bad code" with no public
>>releases and as time goes by you rewrite more and more of the "bad
>>code" with your own and release that. The beauty in such a technique
>>is that you'll easily trace new bugs back to the source by comparing
>>with the original code.
>>
> I wonder how many people remember what Phoenix Technologies did
>back in early 1980's (I don't from personal experience). They took
>source listings or IBM PC ROM BIOS (perhaps disassemblies too),
>those were published in the Technical Reference. One team studied
>the IBM BIOS extensively and wrote a specification based on it.
>Another team never saw a line of IBM code, only the specs. The
>result was Phoenix BIOS, a perfectly legal clone of IBM BIOS
>which basically enabled the whole PC clone market to exist. I bet
>IBM wasn't very happy about it.
>
>
> Michal
>
>
>
>
>To unsubscribe from this group, send an email to:
>osFree-unsubscribe@yahoogroups.com
>
>
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
Re: Part 9
#259 From: "Lynn H. Maxson" <lmaxson@...>
Date: Sat Feb 23, 2002 11:25 am
Subject: Re: OSFree and our future lynnmaxson
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
Michal Necasek writes:
"Since I obviously can't keep up with your formidable typing
skills, I'll keep it brief. What makes you think it is even
possible to apply manufacturing processes to software?"
Because the manufacturing process is one of specification,
analysis, design, construction, and testing as is the software
development process. The parallelism has never been lost on
software engineers. Both create assemblies from other assemblies
and raw material.
"I would like to know how you imagine the statement reuse would
work. When I have a statement like this:
A = B + 1;
it is evidently NOT reusable - because it cannot stand on its own.
This statement is ambiguous until it is clearly defined what A and
B actually is. If this is not the kind of statement you had in
mind, I'd like to hear what it is."
If the statement appears more than once in one or more different
instances in one or more different assemblies it has been reused.
However, if it is replicated, i.e. each instance is a different
source, it is not reused. If it is not replicated, i.e. exists
only as a single instance in a source database, but retrieved in
place for each use, it is reused. In either instance it is
reusable whether it is reused or not.
In "A = B + 1;" if this is given a context-based name, i.e. 'A = B
+ 1;', then it is possible while syntax checking to see if a
particular statement exists in the source database. If it does,
then that name stands for it in the assembly (the source code).
If it does not, then the editor (performing the syntax checking)
creates a new context-based name in the source database.
Now if you follow this, it means that every unique source
statement is given a context-based name. It means that the raw
material, the source statements, have names as do assemblies. You
do not have to store the assemblies as fully expanded source code,
but only as a sequence of names, each of which may name another
assembly or raw material.
A "bill of material", i.e. a logical organization representing
some high level construct (say a program), is a named assembly of
names and so on down to the lowest level. In this manner all
software constructs have a manufacturing parallel with reuse down
to the raw material level. This capability does not exist in
current software tools which only allows reuse of components at a
file level. A file is an assembly and thus only permits reuse at
an assembly level, not at a raw material (source statement) level.
The fact of the matter is that 'A' and 'B' in your example
statement are data. You are probably a C programmer. Thus 'A'
and 'B' are data elements, i.e. raw material. In PL/I, however,
they could be data aggregates, i.e. assemblies, either homogenous
(vectors, arrays, matrices, etc.) or heterogeneous (structures) or
any combination thereof as PL/I (and APL) support operations on
aggregate operands.
The point is that you don't know what 'A' or 'B' is until you
define them. In PL/I this occurs in a 'declare' statement, e.g.
'dcl (A,B) fixed bin (31);'. Now this statement can also receive
a context-based name and is reusable.
What you have to grasp here is that this reusability is automatic,
a builtin feature of the software itself. So no matter how many
different times different people write the same source statement
in their source code, the software gives that source statement a
context-based name with the actual source statement existing only
once in the source database regardless of number of uses.
So you write source code as you normally would without concern for
reuse. The software will automatically guarantee statement reuse.
No source statement will ever appear more than once in the source
database. What will appear more than once in every instance of
its use is the source statement's name. An assembly, something
consisting of multiple source statements, is stored, retrieved,
and maintained as an ordered list of names, the order being the
same as they should appear in the source.
Now 'A' and 'B' are referents, things referred to in source
statements. The source statements then are the references, places
where things are referred to, while the things referred to are
referents. Referents like references are separately defined,
stored, retrieved, and maintained from references (source
statements). 'A' and 'B' are also context-based names: A and B.
As stated before they are either elementary data types (raw
material) or aggregates (assemblies). If aggregates, they contain
the names of other aggregates and raw material and so on down
until decomposition in the raw material level completely within
each aggregate.
Assume then that you have two tables in a relational database, one
for source statements (references) and one for source data types
(referents). Each row of each table stores only the raw material
source: elementary data type (referent raw material) and source
statement (reference raw material). Both have names existing in a
common directory, another table in our relational database.
Each row in our directory table contains a unique name of a
referent or a reference. Now we have other tables in our
directory that allow us to store ordered sets of names: assemblies
of referents (aggregates) and references (modules, procedures,
programs, etc.). Each of these has a unique name.
Now how do we guarantee their uniqueness? By giving them an
index. Thus every unique name consists of a "proper name"
appended by an index value. This allows us to handle the instance
of homonyms, things that have the same proper name but different
contexts. This leaves us only to consider instances of synonyms,
things which have different names but the same context. For this,
synonyms, we need another table to cross-reference all synonym
instances to a single source, an "alias" table.
What happens now is that it is possible to have the software
store, retrieve, and maintain referents and references
automatically guaranteeing reuse at the raw material and assembly
level. You have now created a production and inventory control
system (PICS) exactly parallel (matching) to that which occurs in
manufacturing.
What I have covered here is a true source database with a data
directory. In this explanation it's a relational database with
multiple tables. That says it is possible to query all source,
referents and references, raw material and assemblies, as data.
If you want to change a source statement in an assembly and you
need to know (1) what assemblies contain this source statement or
(2) what assemblies use this assembly, it's a simple SQL query.
It gives you the global, across all systems impact of a change.
The same is true if you change a half-word binary referent, e.g.
'dcl A fixed bin (15);', to a full-word, 'dcl A fixed bin (31);'.
You can look at all the references which use it, i.e. "where
used".
I won't bother you with the ability to use pattern-matching AI
algorithms to seek out potential assemblies for reuse. The point
is enabling the software to perform the clerical tasks now
performed manually. Having all source in a source database and
eliminating the use of source files and having a directory of all
names (referents and references, raw material and assemblies),
gives the IT enterprise a level of control and administration,
e.g. enforcement of use and naming standards, that it does not now
have. I won't bother you with the fact that the use of an index
value as part of a unique name creates a builtin version control
unmatched by any existing tool, particularly CVS.
You will also discover that you can do the same for source text
which has source statements (raw material) of its own from which
higher level assemblies (paragraphs, sections, chapters, books,
...) are constructed. These too are references whose referents
are the same as the source code. You can now construct assemblies
of source text only, source code only, or combinations of source
text and code. That means that you can now "document" code
instead of "commenting" it, making such documentation
automatically reusable and reused.
It goes on and on with respect to the possibilities of this
approach to that of existing source files. You cannot achieve
Knuth's "Literate Programming" style with source files. You must
have a means of loosely coupling text and code and allowing
different organizations of the same source to exist concurrently.
So, yes, I do believe that it is possible to manufacture software
from reusable components. You simply have to recognize that every
source statement is reusable. If you do, then you store,
retrieve, and maintain it as such. We do not do that currently in
any of our tools.
Date: Sat Feb 23, 2002 11:25 am
Subject: Re: OSFree and our future lynnmaxson
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
Michal Necasek writes:
"Since I obviously can't keep up with your formidable typing
skills, I'll keep it brief. What makes you think it is even
possible to apply manufacturing processes to software?"
Because the manufacturing process is one of specification,
analysis, design, construction, and testing as is the software
development process. The parallelism has never been lost on
software engineers. Both create assemblies from other assemblies
and raw material.
"I would like to know how you imagine the statement reuse would
work. When I have a statement like this:
A = B + 1;
it is evidently NOT reusable - because it cannot stand on its own.
This statement is ambiguous until it is clearly defined what A and
B actually is. If this is not the kind of statement you had in
mind, I'd like to hear what it is."
If the statement appears more than once in one or more different
instances in one or more different assemblies it has been reused.
However, if it is replicated, i.e. each instance is a different
source, it is not reused. If it is not replicated, i.e. exists
only as a single instance in a source database, but retrieved in
place for each use, it is reused. In either instance it is
reusable whether it is reused or not.
In "A = B + 1;" if this is given a context-based name, i.e. 'A = B
+ 1;', then it is possible while syntax checking to see if a
particular statement exists in the source database. If it does,
then that name stands for it in the assembly (the source code).
If it does not, then the editor (performing the syntax checking)
creates a new context-based name in the source database.
Now if you follow this, it means that every unique source
statement is given a context-based name. It means that the raw
material, the source statements, have names as do assemblies. You
do not have to store the assemblies as fully expanded source code,
but only as a sequence of names, each of which may name another
assembly or raw material.
A "bill of material", i.e. a logical organization representing
some high level construct (say a program), is a named assembly of
names and so on down to the lowest level. In this manner all
software constructs have a manufacturing parallel with reuse down
to the raw material level. This capability does not exist in
current software tools which only allows reuse of components at a
file level. A file is an assembly and thus only permits reuse at
an assembly level, not at a raw material (source statement) level.
The fact of the matter is that 'A' and 'B' in your example
statement are data. You are probably a C programmer. Thus 'A'
and 'B' are data elements, i.e. raw material. In PL/I, however,
they could be data aggregates, i.e. assemblies, either homogenous
(vectors, arrays, matrices, etc.) or heterogeneous (structures) or
any combination thereof as PL/I (and APL) support operations on
aggregate operands.
The point is that you don't know what 'A' or 'B' is until you
define them. In PL/I this occurs in a 'declare' statement, e.g.
'dcl (A,B) fixed bin (31);'. Now this statement can also receive
a context-based name and is reusable.
What you have to grasp here is that this reusability is automatic,
a builtin feature of the software itself. So no matter how many
different times different people write the same source statement
in their source code, the software gives that source statement a
context-based name with the actual source statement existing only
once in the source database regardless of number of uses.
So you write source code as you normally would without concern for
reuse. The software will automatically guarantee statement reuse.
No source statement will ever appear more than once in the source
database. What will appear more than once in every instance of
its use is the source statement's name. An assembly, something
consisting of multiple source statements, is stored, retrieved,
and maintained as an ordered list of names, the order being the
same as they should appear in the source.
Now 'A' and 'B' are referents, things referred to in source
statements. The source statements then are the references, places
where things are referred to, while the things referred to are
referents. Referents like references are separately defined,
stored, retrieved, and maintained from references (source
statements). 'A' and 'B' are also context-based names: A and B.
As stated before they are either elementary data types (raw
material) or aggregates (assemblies). If aggregates, they contain
the names of other aggregates and raw material and so on down
until decomposition in the raw material level completely within
each aggregate.
Assume then that you have two tables in a relational database, one
for source statements (references) and one for source data types
(referents). Each row of each table stores only the raw material
source: elementary data type (referent raw material) and source
statement (reference raw material). Both have names existing in a
common directory, another table in our relational database.
Each row in our directory table contains a unique name of a
referent or a reference. Now we have other tables in our
directory that allow us to store ordered sets of names: assemblies
of referents (aggregates) and references (modules, procedures,
programs, etc.). Each of these has a unique name.
Now how do we guarantee their uniqueness? By giving them an
index. Thus every unique name consists of a "proper name"
appended by an index value. This allows us to handle the instance
of homonyms, things that have the same proper name but different
contexts. This leaves us only to consider instances of synonyms,
things which have different names but the same context. For this,
synonyms, we need another table to cross-reference all synonym
instances to a single source, an "alias" table.
What happens now is that it is possible to have the software
store, retrieve, and maintain referents and references
automatically guaranteeing reuse at the raw material and assembly
level. You have now created a production and inventory control
system (PICS) exactly parallel (matching) to that which occurs in
manufacturing.
What I have covered here is a true source database with a data
directory. In this explanation it's a relational database with
multiple tables. That says it is possible to query all source,
referents and references, raw material and assemblies, as data.
If you want to change a source statement in an assembly and you
need to know (1) what assemblies contain this source statement or
(2) what assemblies use this assembly, it's a simple SQL query.
It gives you the global, across all systems impact of a change.
The same is true if you change a half-word binary referent, e.g.
'dcl A fixed bin (15);', to a full-word, 'dcl A fixed bin (31);'.
You can look at all the references which use it, i.e. "where
used".
I won't bother you with the ability to use pattern-matching AI
algorithms to seek out potential assemblies for reuse. The point
is enabling the software to perform the clerical tasks now
performed manually. Having all source in a source database and
eliminating the use of source files and having a directory of all
names (referents and references, raw material and assemblies),
gives the IT enterprise a level of control and administration,
e.g. enforcement of use and naming standards, that it does not now
have. I won't bother you with the fact that the use of an index
value as part of a unique name creates a builtin version control
unmatched by any existing tool, particularly CVS.
You will also discover that you can do the same for source text
which has source statements (raw material) of its own from which
higher level assemblies (paragraphs, sections, chapters, books,
...) are constructed. These too are references whose referents
are the same as the source code. You can now construct assemblies
of source text only, source code only, or combinations of source
text and code. That means that you can now "document" code
instead of "commenting" it, making such documentation
automatically reusable and reused.
It goes on and on with respect to the possibilities of this
approach to that of existing source files. You cannot achieve
Knuth's "Literate Programming" style with source files. You must
have a means of loosely coupling text and code and allowing
different organizations of the same source to exist concurrently.
So, yes, I do believe that it is possible to manufacture software
from reusable components. You simply have to recognize that every
source statement is reusable. If you do, then you store,
retrieve, and maintain it as such. We do not do that currently in
any of our tools.
Re: Part 9
#260 From: "Oliver Stein" <ostein@...>
Date: Sat Feb 23, 2002 12:10 pm
Subject: Re: Digest Number 9 O_Stein
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
Hi all,
>It's interseting what OpenBeOS states about the
>same problem in they're faq:
>http://open-beos.sourceforge.net/faq.php
very intresting indeed. Everone on this list should read it.
Ok, I'm not a (kernel) programmer myself, but this NewOS sounds interesting...
Anyone here that has seen it or knows anything about it?
A portable microkernel with multiple personalities on top - now, WHERE have I
heared that before? *g*
Regards / Mit freundlichen GrьЯen,
Oliver Stein
InnoTek Systemberatung GmbH
InnoTek at the CeBIT fair (March 13-20, 2002, Hannover, Germany):
Hall 4, booth A04 (IBM Partner booth), demo point D.03
------------------------------------------------------------
http://www.innotek.de
Date: Sat Feb 23, 2002 12:10 pm
Subject: Re: Digest Number 9 O_Stein
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
Hi all,
>It's interseting what OpenBeOS states about the
>same problem in they're faq:
>http://open-beos.sourceforge.net/faq.php
very intresting indeed. Everone on this list should read it.
Ok, I'm not a (kernel) programmer myself, but this NewOS sounds interesting...
Anyone here that has seen it or knows anything about it?
A portable microkernel with multiple personalities on top - now, WHERE have I
heared that before? *g*
Regards / Mit freundlichen GrьЯen,
Oliver Stein
InnoTek Systemberatung GmbH
InnoTek at the CeBIT fair (March 13-20, 2002, Hannover, Germany):
Hall 4, booth A04 (IBM Partner booth), demo point D.03
------------------------------------------------------------
http://www.innotek.de