#161 From: "ltning99" <ltning@...>
Date: Wed Feb 20, 2002 10:51 am
Subject: Re: My take on this.. ltning99
Online Now Online Now
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
Hi,
> but you just agreed to having comitted a crime.
Yes I did. Unlike some others.
> Assuming the development team has used the code you have, do
> they state they own the code ?
They have released a product they claim to be theirs. Isn't that
pretty much the same?
> Giving away "stolen goods" does not generally give harder punishment
> than having them.
Wrong. If you steal a car for your own use, you get X years in jail.
If you steal a car (or many cars) and then sell it (them), you get Y
years in jail, where Y>X and probably Y>(2X) in many cases. Both are
illegal, but one is a less seirous crime than the other.
> Unless a plaintif wins a case in court nothing is illegal.
Bwaahahaha... So you mean that all the guys running around in the
world having raped and killed little kids and gotten away with it
haven't done anything illegal? Come on.. Even you have to see the
absurdity of that statement...
> You on the other hand has willingly admitted to having as you call it
> "stolen" property. It would be a quite easy case if they were to sue
> you.
I could just be bragging.
> I must thank you though. This tells us that there is really a leaked
> source.
You didn't know before now? What container have you been living in?
> I hope someone spreads this so that everyone could get hold of it and
> get to know more about how OS/2 really work.
It seems I didn't state this clearly enough: Anyone who uses this
source to produce something has committed a crime, and noone could
ever use it without also doing so. Thus the product, whatever it is,
is virtually worthless except to those few who chooses to ignore the
fact that it's an illegal product (Which will admitteldy be a few, but
not enough to keep an application, much less an operating system, alive).
-Eirik
Part 6 - Feb 21 2002
Re: Part 6
#162 From: "Michal Necasek" <michaln@...>
Date: Fri Feb 22, 2002 3:46 am
Subject: Re: Re: My take on this.. michalnec
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
On Wed, 20 Feb 2002 07:51:09 -0000, ltning99 wrote:
Eirik,
>> Unless a plaintif wins a case in court nothing is illegal.
>
>Bwaahahaha... So you mean that all the guys running around in the
>world having raped and killed little kids and gotten away with it
>haven't done anything illegal? Come on.. Even you have to see the
>absurdity of that statement...
>
The point is that you can't just run around pointing fingers
and screaming "He's a rapist!". Presumption of innocence and all
that you know. And saying "I know they stole it because I stole
it too" does sound a bit funny, don't you think?
Michal
Date: Fri Feb 22, 2002 3:46 am
Subject: Re: Re: My take on this.. michalnec
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
On Wed, 20 Feb 2002 07:51:09 -0000, ltning99 wrote:
Eirik,
>> Unless a plaintif wins a case in court nothing is illegal.
>
>Bwaahahaha... So you mean that all the guys running around in the
>world having raped and killed little kids and gotten away with it
>haven't done anything illegal? Come on.. Even you have to see the
>absurdity of that statement...
>
The point is that you can't just run around pointing fingers
and screaming "He's a rapist!". Presumption of innocence and all
that you know. And saying "I know they stole it because I stole
it too" does sound a bit funny, don't you think?
Michal
Re: Part 6
#163 From: "JMA" <mail@...>
Date: Fri Feb 22, 2002 4:10 am
Subject: Re: Re: My take on this.. (useless discussion) mailjmase
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
On Wed, 20 Feb 2002 07:51:09 -0000, ltning99 wrote:
>> Giving away "stolen goods" does not generally give harder punishment
>> than having them.
>
>Wrong. If you steal a car for your own use, you get X years in jail.
>If you steal a car (or many cars) and then sell it (them), you get Y
>years in jail, where Y>X and probably Y>(2X) in many cases. Both are
>illegal, but one is a less seirous crime than the other.
>
Who said selling !
Selling is just the thing that separates it all.
Did you know that anyone can use/build a patented thing as long
as you dont make any money out of it.
>> Unless a plaintif wins a case in court nothing is illegal.
>
>Bwaahahaha... So you mean that all the guys running around in the
>world having raped and killed little kids and gotten away with it
>haven't done anything illegal? Come on.. Even you have to see the
>absurdity of that statement...
>
Then how will you know who got away and who was innocent.
Or should we just kill everyone of them to be sure.
>> You on the other hand has willingly admitted to having as you call it
>> "stolen" property. It would be a quite easy case if they were to sue
>> you.
>
>I could just be bragging.
>
You could, but you would still be sued.
Also, according to your statement above it hardly matters if you get of in
court since we cannot trust the courts. You did it you are guilty.
>> I must thank you though. This tells us that there is really a leaked
>> source.
>
>You didn't know before now? What container have you been living in?
>
I can tell you LOTS of people did not know this !
How would I know there was a leak ?
Is it on hobbes or any other site, does people speak about it in public
newsgroups ? Does it come on the hobbes CDROM's.
Seems your part of a secret brotherhood that thinks you should be
allowed to have the code but noone else.
I'd assume you are in some way better then the rest of us ?
But its useless to discuss these things !!
I want an opensource OS/2. Are you interested in helping in helping out ?
If there is anything wrong with the TPE distro then throw it away.
Either you have an interest in a OpenSource OS/2 clone and wants
to help or you should get off this list do do something else.
Sincerely
JMA
Development and Consulting
John Martin , jma@...
==================================
Website: http://www.jma.se/
email: mail@...
Phone: 46-(0)70-6278410
==================================
Date: Fri Feb 22, 2002 4:10 am
Subject: Re: Re: My take on this.. (useless discussion) mailjmase
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
On Wed, 20 Feb 2002 07:51:09 -0000, ltning99 wrote:
>> Giving away "stolen goods" does not generally give harder punishment
>> than having them.
>
>Wrong. If you steal a car for your own use, you get X years in jail.
>If you steal a car (or many cars) and then sell it (them), you get Y
>years in jail, where Y>X and probably Y>(2X) in many cases. Both are
>illegal, but one is a less seirous crime than the other.
>
Who said selling !
Selling is just the thing that separates it all.
Did you know that anyone can use/build a patented thing as long
as you dont make any money out of it.
>> Unless a plaintif wins a case in court nothing is illegal.
>
>Bwaahahaha... So you mean that all the guys running around in the
>world having raped and killed little kids and gotten away with it
>haven't done anything illegal? Come on.. Even you have to see the
>absurdity of that statement...
>
Then how will you know who got away and who was innocent.
Or should we just kill everyone of them to be sure.
>> You on the other hand has willingly admitted to having as you call it
>> "stolen" property. It would be a quite easy case if they were to sue
>> you.
>
>I could just be bragging.
>
You could, but you would still be sued.
Also, according to your statement above it hardly matters if you get of in
court since we cannot trust the courts. You did it you are guilty.
>> I must thank you though. This tells us that there is really a leaked
>> source.
>
>You didn't know before now? What container have you been living in?
>
I can tell you LOTS of people did not know this !
How would I know there was a leak ?
Is it on hobbes or any other site, does people speak about it in public
newsgroups ? Does it come on the hobbes CDROM's.
Seems your part of a secret brotherhood that thinks you should be
allowed to have the code but noone else.
I'd assume you are in some way better then the rest of us ?
But its useless to discuss these things !!
I want an opensource OS/2. Are you interested in helping in helping out ?
If there is anything wrong with the TPE distro then throw it away.
Either you have an interest in a OpenSource OS/2 clone and wants
to help or you should get off this list do do something else.
Sincerely
JMA
Development and Consulting
John Martin , jma@...
==================================
Website: http://www.jma.se/
email: mail@...
Phone: 46-(0)70-6278410
==================================
Re: Part 6
#164 From: "drittervonfuenf" <3rdof5@...>
Date: Fri Feb 22, 2002 4:44 am
Subject: Stay with the current Kernel. drittervonfuenf
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
Well lets compare OS/2 and NT
In NT everything is more streamlined, and all drivers and
components are tighly integrated into the system.
OS/2 is just a bunch of tools glued together and sometimes
even without glue (look at a normal W4 install).
Every OS/2 test in the prev. years always said so, and lucky
us they are right!
OS/2 is a very modular OS unlike NT or Linux(new driver change
the kernel).
The kernel is quite stable, it does it task very well and
there are no big showstoping bugs in it. So lets keep it for a
while.
What are the "problem" areas to run OS/2 on x32 HW in the
future (I don't see a world without A20 gate in the next 10
years!) ? Drivers and Applications.
- Graphiccards: We have SDD so most cards do run quite well.
- Sound drivers: Are also soon no issue as there'll be the a
port of the ALSA soundsystem for OS/2 in short time as
annound on the DDK list last week.
So what other big device groups are needed,
- Networking :ugly asm sample in DDK linux sources
- PCMICA : Sources Available in the DDK
- USB : Sources Available in the DDK
- IEEE1394 : Linux sources
Now for applications:
there are 3 big projects to get more apps to OS/2 lets look at
them
- ODIN : Quite advanced considdering that there are currently
about 6 developers working on it and at no time more
than 12 at a time. I think 4 people wrote 80% of the
code.
- UnixOS2 : 4-6? Developers
- Everblue: 2 Developers
So if we want to do something we should add more development
power these projects and maybe start rewriting PM. as we won't
get bugfixes there. We can also easily replace other modules
like do an IPv6 stack, rewrite MMPM or the WPS.
Concentrating on the Dos Mou Key calls etc is the totally
wrong approach. Why? They are the most stable part of the
system and are highly integrated into the kernel (Dos APIs
do give you direct access to internal Kernal structures).
So as we don't know what kernel we'll take we should stay away
from them. If we rewrite PM that code is totally undepended
and protable. same for all the higher modules. And a free WPS
implementation might even get developer resource from the
outside. So lets start replacing the high level DLLs one by
one. Replace Ini files with a real DB so we don't get any more
ini corruptions think about the weak points and fix them.
Write a universal network driver so that poring a linux
networking driver is easy. Def help ODIN as it'll address
also Driver problems in the near future. As Windows moves
to usermode that is normal DLL based drivers, like all
Scanners, digital cameras are handled that way.
Lets focus on things which help now on OS/2 but are a longterm
investment of developement resources.
Well it's gets late
more later 2day
Markus
Date: Fri Feb 22, 2002 4:44 am
Subject: Stay with the current Kernel. drittervonfuenf
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
Well lets compare OS/2 and NT
In NT everything is more streamlined, and all drivers and
components are tighly integrated into the system.
OS/2 is just a bunch of tools glued together and sometimes
even without glue (look at a normal W4 install).
Every OS/2 test in the prev. years always said so, and lucky
us they are right!
OS/2 is a very modular OS unlike NT or Linux(new driver change
the kernel).
The kernel is quite stable, it does it task very well and
there are no big showstoping bugs in it. So lets keep it for a
while.
What are the "problem" areas to run OS/2 on x32 HW in the
future (I don't see a world without A20 gate in the next 10
years!) ? Drivers and Applications.
- Graphiccards: We have SDD so most cards do run quite well.
- Sound drivers: Are also soon no issue as there'll be the a
port of the ALSA soundsystem for OS/2 in short time as
annound on the DDK list last week.
So what other big device groups are needed,
- Networking :ugly asm sample in DDK linux sources
- PCMICA : Sources Available in the DDK
- USB : Sources Available in the DDK
- IEEE1394 : Linux sources
Now for applications:
there are 3 big projects to get more apps to OS/2 lets look at
them
- ODIN : Quite advanced considdering that there are currently
about 6 developers working on it and at no time more
than 12 at a time. I think 4 people wrote 80% of the
code.
- UnixOS2 : 4-6? Developers
- Everblue: 2 Developers
So if we want to do something we should add more development
power these projects and maybe start rewriting PM. as we won't
get bugfixes there. We can also easily replace other modules
like do an IPv6 stack, rewrite MMPM or the WPS.
Concentrating on the Dos Mou Key calls etc is the totally
wrong approach. Why? They are the most stable part of the
system and are highly integrated into the kernel (Dos APIs
do give you direct access to internal Kernal structures).
So as we don't know what kernel we'll take we should stay away
from them. If we rewrite PM that code is totally undepended
and protable. same for all the higher modules. And a free WPS
implementation might even get developer resource from the
outside. So lets start replacing the high level DLLs one by
one. Replace Ini files with a real DB so we don't get any more
ini corruptions think about the weak points and fix them.
Write a universal network driver so that poring a linux
networking driver is easy. Def help ODIN as it'll address
also Driver problems in the near future. As Windows moves
to usermode that is normal DLL based drivers, like all
Scanners, digital cameras are handled that way.
Lets focus on things which help now on OS/2 but are a longterm
investment of developement resources.
Well it's gets late
more later 2day
Markus
Re: Part 6
#165 From: "Michal Necasek" <michaln@...>
Date: Fri Feb 22, 2002 5:29 am
Subject: Re: Stay with the current Kernel. michalnec
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
On Fri, 22 Feb 2002 01:44:59 -0000, drittervonfuenf wrote:
Hi Markus,
>Well lets compare OS/2 and NT
>In NT everything is more streamlined, and all drivers and
>components are tighly integrated into the system.
>
Meaning that any change breaks who knows what who knows
where. Not something we'd want
The WDM for instance is on the one hand very well defined
but on the other very limiting. The OS/2 driver model
is in comparison rather free-form. It is hard to say which
is easier (or more difficult?) to write for. Both have
advantages and disadvantages.
>OS/2 is just a bunch of tools glued together and sometimes
>even without glue (look at a normal W4 install).
>Every OS/2 test in the prev. years always said so, and lucky
>us they are right!
>
Modular programming is a wonderful concept. OOP is just
an extension (or rehash?) of the same. Nobody has invented
anything better. In my experience modules written in OOP
languages end up being a lot less modular than others but
heck, it's not my fault that I don't like C++ (but SOM
is cool and fixes many of the problems C++ has)
>OS/2 is a very modular OS unlike NT or Linux(new driver change
>the kernel).
>
Unix as an OS is extremely modular but the kernel surely
isn't. And that's one of the major problems Linux has. And
yes, NT is a lot less modular than OS/2. In OS/2 the seams
are sometimes a bit too visible but the resulting flexibility
is IMHO well worth it.
>The kernel is quite stable, it does it task very well and
>there are no big showstoping bugs in it. So lets keep it for a
>while.
>
You must be reading my mind There are some things in
the kernel that should be fixed and some that could be fixed
fairly easily. The only real problem with the current OS/2
kernel that I see is that it's a little too easy to get
unkillable processes. But then again I wonder if any
"desktop" OS solves this problem 100%? I know for sure that
NT/W2K doesn't, despite what its advocates claim.
And the OS/2 kernel is fairly slim and performs very well.
Plus it's quite stable as long as you don't use every cutting
edge testcase version (I think "cutting edge" means "watch
out, you could cut yourself").
>So what other big device groups are needed,
>- Networking :ugly asm sample in DDK linux sources
>
Actually the networking situation isn't that bad. All
good NICs I know have OS/2 drivers (Intel, 3Com, linkSys...)
Personally I don't see much value in supporting every piece
of $5 crap on the market.
>- PCMICA : Sources Available in the DDK
>
You mean PCMCIA
>So if we want to do something we should add more development
>power these projects and maybe start rewriting PM. as we won't
>get bugfixes there.
>
Very true. And PM needs a LOT more fixing than the kernel.
While some significant work on the kernel has been done for
WSeB and thanks to Scott G the kernel is being continuously
enhanced, the PM has not changed in years. The only "recent"
change in PM that I can think of is the "enhanced stretching".
And remember how many FixPaks it took to get the worst kinks
out and some remaining ones are deemed "not fixable" (don't
believe that).
>Concentrating on the Dos Mou Key calls etc is the totally
>wrong approach. Why? They are the most stable part of the
>system and are highly integrated into the kernel (Dos APIs
>do give you direct access to internal Kernal structures).
>
Not really I mean, apps are normally not interested
in the PTDA, SFT and so on, nor can they access these
structures easily.
>Write a universal network driver so that poring a linux
>networking driver is easy. Def help ODIN as it'll address
>also Driver problems in the near future.
>
Micrografx Oasis revisited - ten years later<g>?
Anyway I don't see why the development couldn't work
in BOTH directions at once. There is no reason why one
or more groups couldn't be replacing userland code and
another group working on the kernel. As long as they keep
their work compatible with current OS/2, they'll be
automagically compatible with each other.
I see the value of osFree (or should I say an open source
OS/2 compatible kernel) in that you could get a small, not
very full featured but working OS with potential non-commerical
(and hopefully commercial too) applications. If it were open
source, it would be possible to build stripped down versions
of the kernel more suitable for their job. Example: a network
router doesn't need the MVDM support.
Michal
Date: Fri Feb 22, 2002 5:29 am
Subject: Re: Stay with the current Kernel. michalnec
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
On Fri, 22 Feb 2002 01:44:59 -0000, drittervonfuenf wrote:
Hi Markus,
>Well lets compare OS/2 and NT
>In NT everything is more streamlined, and all drivers and
>components are tighly integrated into the system.
>
Meaning that any change breaks who knows what who knows
where. Not something we'd want
The WDM for instance is on the one hand very well defined
but on the other very limiting. The OS/2 driver model
is in comparison rather free-form. It is hard to say which
is easier (or more difficult?) to write for. Both have
advantages and disadvantages.
>OS/2 is just a bunch of tools glued together and sometimes
>even without glue (look at a normal W4 install).
>Every OS/2 test in the prev. years always said so, and lucky
>us they are right!
>
Modular programming is a wonderful concept. OOP is just
an extension (or rehash?) of the same. Nobody has invented
anything better. In my experience modules written in OOP
languages end up being a lot less modular than others but
heck, it's not my fault that I don't like C++ (but SOM
is cool and fixes many of the problems C++ has)
>OS/2 is a very modular OS unlike NT or Linux(new driver change
>the kernel).
>
Unix as an OS is extremely modular but the kernel surely
isn't. And that's one of the major problems Linux has. And
yes, NT is a lot less modular than OS/2. In OS/2 the seams
are sometimes a bit too visible but the resulting flexibility
is IMHO well worth it.
>The kernel is quite stable, it does it task very well and
>there are no big showstoping bugs in it. So lets keep it for a
>while.
>
You must be reading my mind There are some things in
the kernel that should be fixed and some that could be fixed
fairly easily. The only real problem with the current OS/2
kernel that I see is that it's a little too easy to get
unkillable processes. But then again I wonder if any
"desktop" OS solves this problem 100%? I know for sure that
NT/W2K doesn't, despite what its advocates claim.
And the OS/2 kernel is fairly slim and performs very well.
Plus it's quite stable as long as you don't use every cutting
edge testcase version (I think "cutting edge" means "watch
out, you could cut yourself").
>So what other big device groups are needed,
>- Networking :ugly asm sample in DDK linux sources
>
Actually the networking situation isn't that bad. All
good NICs I know have OS/2 drivers (Intel, 3Com, linkSys...)
Personally I don't see much value in supporting every piece
of $5 crap on the market.
>- PCMICA : Sources Available in the DDK
>
You mean PCMCIA
>So if we want to do something we should add more development
>power these projects and maybe start rewriting PM. as we won't
>get bugfixes there.
>
Very true. And PM needs a LOT more fixing than the kernel.
While some significant work on the kernel has been done for
WSeB and thanks to Scott G the kernel is being continuously
enhanced, the PM has not changed in years. The only "recent"
change in PM that I can think of is the "enhanced stretching".
And remember how many FixPaks it took to get the worst kinks
out and some remaining ones are deemed "not fixable" (don't
believe that).
>Concentrating on the Dos Mou Key calls etc is the totally
>wrong approach. Why? They are the most stable part of the
>system and are highly integrated into the kernel (Dos APIs
>do give you direct access to internal Kernal structures).
>
Not really I mean, apps are normally not interested
in the PTDA, SFT and so on, nor can they access these
structures easily.
>Write a universal network driver so that poring a linux
>networking driver is easy. Def help ODIN as it'll address
>also Driver problems in the near future.
>
Micrografx Oasis revisited - ten years later<g>?
Anyway I don't see why the development couldn't work
in BOTH directions at once. There is no reason why one
or more groups couldn't be replacing userland code and
another group working on the kernel. As long as they keep
their work compatible with current OS/2, they'll be
automagically compatible with each other.
I see the value of osFree (or should I say an open source
OS/2 compatible kernel) in that you could get a small, not
very full featured but working OS with potential non-commerical
(and hopefully commercial too) applications. If it were open
source, it would be possible to build stripped down versions
of the kernel more suitable for their job. Example: a network
router doesn't need the MVDM support.
Michal
Re: Part 6
#166 From: "Lynn H. Maxson" <lmaxson@...>
Date: Fri Feb 22, 2002 5:54 am
Subject: Re: OSFree and our future lynnmaxson
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
Michael Necasek writes:
"That's a VERY good point. These guys got it all wrong. They think
they can design a working kernel while sitting in an armchair.
That is unfortunately nonsense. It doesn't work that way and there
is one simple reason: until you implement something, you do not
know what problems you will face."
That assumes that they have never implemented anything or that no
implementation exists. In either instance you have these
experiences and the problems, if any, associated with them. Given
a set of such instances recorded either in source code or source
text allows you to return to your armchair, take advantage of
these experiences, and move forward with confidence of your
results.
"Some silly people compare software engineering to civil
engineering to prove how stupid SW engineers are. They say, look,
an engineer can build a bridge or a building without schedule
slippages and delays and additional expenses and whatnot. If you
SW guys can't do it, you must be doing it all wrong."
Unfortunately it wasn't the civil engineers saying this. It was
the so-called software engineers. They believed that you should
be able to "engineer" software in the same manner you engineered
hardware, whether a computer or a bridge. The key they felt was
in maximising use, i.e. reuse, of components. The component they
chose was objects, a hierarchical class arrangement of data and
methods using messaging as intercommunication. It was the
so-called software engineers who claimed that such capability
would allow them to produce the same results as civil (mechanical,
electrical, electronic) engineers.
The difficulty, of course, lay in the differences of reusable
components, the different levels of abstraction from raw material
to higher level assemblies. In "real" engineering, in
manufacturing, this is known as constructing a Bill of Material
(BOM). The difference between a software BOM, as defined by OO
software engineers, is that the lowest "raw material", i.e.
component or object, is itself still an assembly. Whereas in fact
the raw material, that from which all higher level derive and must
decompose into, are source statements, either code or text.
Now you have no tool available to you which supports statements as
the basic or lowest level raw material. In short you have only a
partial implementation of a "true" manufacturing process. Thus
you have "silly" things in your programs preceded by an "include"
statement, which doesn't include anything at "edit" time, thus
denying the assembly beforehand of the actual source. Moreover it
forces the "replication" of statements in every instance of use,
instead of a single source incorporated within every instance of
use.
The other things that software engineers don't allow with their
tools, particularly compilers, is the construction of a system,
the bridge under question. So if a software system consists of
multiple parts, i.e. external procedures, each part must be
process separately (piece or part engineering) instead of the
processing of the whole (system engineering).
What is strange in all this that in the normal software
development cycle of specification, analysis, design,
construction, and testing that with the exception of construction,
the coding phase which is your security blanket, all the other
stages (specification, analysis, design, and testing) do permit
system level processing. In analysis and design this system level
processing is specifically supported by CASE tools.
Basically in construction the lack of system level tools or
processing breaks down the development process as a whole from the
earlier stages of specification, analysis, and design and from the
following stage of testing. That fault lies with coders,
euphemistically known as programmers, who have no grasp of
manufacturing, system level manufacturing, as it exists in other
engineering arenas.
Until you eliminate treating an assembly, i.e. an object
consisting of data and methods, as raw material, allow reuse only
through a restricted form of inheritance, and allow the generation
of multiple executables as a single unit of work from a single set
of unordered source code, as it exists in common production and
inventory control systems (PICS), you cannot blame the civil (or
every other) engineers for questioning the integrity of software
engineers.
" Well, to that I say, this analogy would hold if every building,
every bridge was considerably different from previous ones, built
with new and unproven materials and if the builders several times
changed their minds where the bridge was to actually stand."
As long as you are willing to deny the principle of reuse, the
heart and soul of OO technology, I have no argument. It's whole
claimed purpose was to avoid or reduce the impact of the
deficiencies you mention. If you do not believe in code reuse,
say so. If you do not believe in the maximum reuse of code or in
the hierarchical class system forming the basis of OO, then say
so. If you do not believe in them, then you certainly cannot
believe in using their tools, their languages and their
implementations of them.
Date: Fri Feb 22, 2002 5:54 am
Subject: Re: OSFree and our future lynnmaxson
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
Michael Necasek writes:
"That's a VERY good point. These guys got it all wrong. They think
they can design a working kernel while sitting in an armchair.
That is unfortunately nonsense. It doesn't work that way and there
is one simple reason: until you implement something, you do not
know what problems you will face."
That assumes that they have never implemented anything or that no
implementation exists. In either instance you have these
experiences and the problems, if any, associated with them. Given
a set of such instances recorded either in source code or source
text allows you to return to your armchair, take advantage of
these experiences, and move forward with confidence of your
results.
"Some silly people compare software engineering to civil
engineering to prove how stupid SW engineers are. They say, look,
an engineer can build a bridge or a building without schedule
slippages and delays and additional expenses and whatnot. If you
SW guys can't do it, you must be doing it all wrong."
Unfortunately it wasn't the civil engineers saying this. It was
the so-called software engineers. They believed that you should
be able to "engineer" software in the same manner you engineered
hardware, whether a computer or a bridge. The key they felt was
in maximising use, i.e. reuse, of components. The component they
chose was objects, a hierarchical class arrangement of data and
methods using messaging as intercommunication. It was the
so-called software engineers who claimed that such capability
would allow them to produce the same results as civil (mechanical,
electrical, electronic) engineers.
The difficulty, of course, lay in the differences of reusable
components, the different levels of abstraction from raw material
to higher level assemblies. In "real" engineering, in
manufacturing, this is known as constructing a Bill of Material
(BOM). The difference between a software BOM, as defined by OO
software engineers, is that the lowest "raw material", i.e.
component or object, is itself still an assembly. Whereas in fact
the raw material, that from which all higher level derive and must
decompose into, are source statements, either code or text.
Now you have no tool available to you which supports statements as
the basic or lowest level raw material. In short you have only a
partial implementation of a "true" manufacturing process. Thus
you have "silly" things in your programs preceded by an "include"
statement, which doesn't include anything at "edit" time, thus
denying the assembly beforehand of the actual source. Moreover it
forces the "replication" of statements in every instance of use,
instead of a single source incorporated within every instance of
use.
The other things that software engineers don't allow with their
tools, particularly compilers, is the construction of a system,
the bridge under question. So if a software system consists of
multiple parts, i.e. external procedures, each part must be
process separately (piece or part engineering) instead of the
processing of the whole (system engineering).
What is strange in all this that in the normal software
development cycle of specification, analysis, design,
construction, and testing that with the exception of construction,
the coding phase which is your security blanket, all the other
stages (specification, analysis, design, and testing) do permit
system level processing. In analysis and design this system level
processing is specifically supported by CASE tools.
Basically in construction the lack of system level tools or
processing breaks down the development process as a whole from the
earlier stages of specification, analysis, and design and from the
following stage of testing. That fault lies with coders,
euphemistically known as programmers, who have no grasp of
manufacturing, system level manufacturing, as it exists in other
engineering arenas.
Until you eliminate treating an assembly, i.e. an object
consisting of data and methods, as raw material, allow reuse only
through a restricted form of inheritance, and allow the generation
of multiple executables as a single unit of work from a single set
of unordered source code, as it exists in common production and
inventory control systems (PICS), you cannot blame the civil (or
every other) engineers for questioning the integrity of software
engineers.
" Well, to that I say, this analogy would hold if every building,
every bridge was considerably different from previous ones, built
with new and unproven materials and if the builders several times
changed their minds where the bridge was to actually stand."
As long as you are willing to deny the principle of reuse, the
heart and soul of OO technology, I have no argument. It's whole
claimed purpose was to avoid or reduce the impact of the
deficiencies you mention. If you do not believe in code reuse,
say so. If you do not believe in the maximum reuse of code or in
the hierarchical class system forming the basis of OO, then say
so. If you do not believe in them, then you certainly cannot
believe in using their tools, their languages and their
implementations of them.
Re: Part 6
#167 From: J Christopher Kennedy <kb7nmu@...>
Date: Fri Feb 22, 2002 5:50 am
Subject: Design is already finished... kb7nmu
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
The design is done. That is, as long as you are interested in an OS/2 API
compatible clone. If you want a super OS that does everything right, go
elsewhere. If we want a cloned OS/2, then the design work is finished.
I repeat that, all design work is finished. It's sitting is several
thousand pages behind me as I write this. It's called the OS/2 Programmer's
Reference. We must make the APIs match. It IS that simple. Everything
else is implementation. Yes, there is some design work in the
implementation, but that is on a case by case basis. If we want to clone
VioSetAnsi, then all the info about what parameters it takes, and what kind
of result it should give are already complete (Volume 3, page 238).
The design work is done. Lets move on to implementation.
--
-----------------------------------------------------------
J Christopher Kennedy <kb7nmu@...>
http://www.dragonbard.com/
-----------------------------------------------------------
Date: Fri Feb 22, 2002 5:50 am
Subject: Design is already finished... kb7nmu
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
The design is done. That is, as long as you are interested in an OS/2 API
compatible clone. If you want a super OS that does everything right, go
elsewhere. If we want a cloned OS/2, then the design work is finished.
I repeat that, all design work is finished. It's sitting is several
thousand pages behind me as I write this. It's called the OS/2 Programmer's
Reference. We must make the APIs match. It IS that simple. Everything
else is implementation. Yes, there is some design work in the
implementation, but that is on a case by case basis. If we want to clone
VioSetAnsi, then all the info about what parameters it takes, and what kind
of result it should give are already complete (Volume 3, page 238).
The design work is done. Lets move on to implementation.
--
-----------------------------------------------------------
J Christopher Kennedy <kb7nmu@...>
http://www.dragonbard.com/
-----------------------------------------------------------
Re: Part 6
#168 From: "Lynn H. Maxson" <lmaxson@...>
Date: Fri Feb 22, 2002 7:05 am
Subject: Re: A gift horse... lynnmaxson
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
John Martin (JMA) writes:
"Lynn, sorry for snipping lots, but I assume you will not take to
much offense if I say you are good at elaborating..."
Not at all. Considering the many things I'm charged with not
being good at, I will take the compliments(?) as they come. I'm
hoping that one can take a strong position without it appearing as
flaming. I have 45 years under my belt working with clients
primarily in software for the manufacturing and distribution
industries. Thus "raw material", components from which all
assemblies spring, and assemblies, components made up of other
assemblies and raw material, have natural correspondence in
software: raw material are sentences (text) and statements (code).
You cannot have "full" reuse without it being to the raw material
level. Without full reuse you have "partial" only, thus
separating you from others capability in their manufacturing
process.
I make no bones that any source code produced here is of no value
to me except as it serves to create specifications. The
specifications are my source code. I have no interest in
furthering C, C++, JAVA, C#, et al as in my mind they are part of
the problem, complicating the solution. None of this, however,
prevents me from participating in documenting these efforts, if
only to insure that I have written my specifications correctly.
The point is that third-generation procedural languages, whether
OO or not, require the procedural construction to occur manually
instead of in software. In OO this procedural construction occurs
in CASE-based UML. Whereas you might have experienced the JSP
(Jackson Structured Programming), I remain an adherent, advocate,
and otherwise firm believer in Constantine's Structured Design of
dataflows and structure charts.
The truth is I no longer believe in the need for manual analysis
and design or construction and testing for that matter. Logic
programming, which goes directly from a set of unordered
specifications to executables, thus performing analysis, design,
and construction in software, has eliminated such a need for over
thirty years now and daily in SQL processing. So if I only need
to write specifications in random order, i.e. the order in which
they occur, and the software will arrange them systematically in
proper order, I see no sense in being continually harmed by an
outdated paradigm of procedural language programming.
I want a system in which a single person can maintain an entire
system, including an operating system, once written. That means
treating it as a system throughout including construction
(coding). We have failed to offer, much less do that, since the
beginning of programming although we have thirty years of
successful logic programming indicating its possibility.
It makes no sense to me to produce an open source system which
lies beyond my or a small handful capabilities to maintain once
developed, once an initial version is available. You cannot
re-implement an entire system without code reuse in 1/10th of the
time without admitting that 9/10ths lies in specification,
analysis, and design. It follows logically, using your own
example, that a far greater and more successful effort lies in
examination than in doing.
You see I want this project to succeed. I want us to use "real"
raw material, thus having reuse at the statement level. I don't
need anything with the complexities and incompatibilities of OO
technology and class libraries. Everything should be potentially
reusable, i.e. compatible. When I have to effect a source change
which impacts multiple, possibly hundreds of modules, I want it to
occur automatically and in sync throughout in software.
The tools to do this do not exist. The tools that do exist,
whether free or not, require more than a small group can develop
and maintain competitively. Microsoft sits with some 38 "billion"
dollars in cash reserves. It can afford to give Windows away for
free and still be on the plus side of the ledger. You cannot beat
Microsoft using essentially its tools or their competitive clones.
When you do you are playing its game, one you will lose as the
JAVA people will discover going up against C# and .Net.
We need to win. To win we must change the rules, force Microsoft,
IBM, and the others to play under our rules instead of, as
currently, theirs. That difference lies in the tool set, in
making "slight" shifts in current paradigms that allows a few to
do what requires many currently. I've mentioned two very
necessary ones: (1) the use of a database of source statements
with a directory of raw material (the source statements) and their
assemblies, and (2) the elimination of a compiler unit of work to
a single external procedure, allowing multiple executables to
occur from within a single compile, a single unit of work.
This last means eliminating the distinction between internal and
external procedures, thus eliminating the practice of physically
"nesting" internal procedures. This allows an unordered set of
procedures to appear as input to a single compile with the
software ordering them into a logical hierarchy of one or more
separate executables. As such we can perform the construction
stage at a system level using software to replace the major
portion of the manual effort now occurring outside software.
At some future point in our progress when we repeatedly stumble
over each other in an attempt to maintain a system as a whole we
will understand how our tools handicap us. Perhaps then we will
see the sense in modifying our tools to allow us to achieve more
through software and do less outside of it.
Date: Fri Feb 22, 2002 7:05 am
Subject: Re: A gift horse... lynnmaxson
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
John Martin (JMA) writes:
"Lynn, sorry for snipping lots, but I assume you will not take to
much offense if I say you are good at elaborating..."
Not at all. Considering the many things I'm charged with not
being good at, I will take the compliments(?) as they come. I'm
hoping that one can take a strong position without it appearing as
flaming. I have 45 years under my belt working with clients
primarily in software for the manufacturing and distribution
industries. Thus "raw material", components from which all
assemblies spring, and assemblies, components made up of other
assemblies and raw material, have natural correspondence in
software: raw material are sentences (text) and statements (code).
You cannot have "full" reuse without it being to the raw material
level. Without full reuse you have "partial" only, thus
separating you from others capability in their manufacturing
process.
I make no bones that any source code produced here is of no value
to me except as it serves to create specifications. The
specifications are my source code. I have no interest in
furthering C, C++, JAVA, C#, et al as in my mind they are part of
the problem, complicating the solution. None of this, however,
prevents me from participating in documenting these efforts, if
only to insure that I have written my specifications correctly.
The point is that third-generation procedural languages, whether
OO or not, require the procedural construction to occur manually
instead of in software. In OO this procedural construction occurs
in CASE-based UML. Whereas you might have experienced the JSP
(Jackson Structured Programming), I remain an adherent, advocate,
and otherwise firm believer in Constantine's Structured Design of
dataflows and structure charts.
The truth is I no longer believe in the need for manual analysis
and design or construction and testing for that matter. Logic
programming, which goes directly from a set of unordered
specifications to executables, thus performing analysis, design,
and construction in software, has eliminated such a need for over
thirty years now and daily in SQL processing. So if I only need
to write specifications in random order, i.e. the order in which
they occur, and the software will arrange them systematically in
proper order, I see no sense in being continually harmed by an
outdated paradigm of procedural language programming.
I want a system in which a single person can maintain an entire
system, including an operating system, once written. That means
treating it as a system throughout including construction
(coding). We have failed to offer, much less do that, since the
beginning of programming although we have thirty years of
successful logic programming indicating its possibility.
It makes no sense to me to produce an open source system which
lies beyond my or a small handful capabilities to maintain once
developed, once an initial version is available. You cannot
re-implement an entire system without code reuse in 1/10th of the
time without admitting that 9/10ths lies in specification,
analysis, and design. It follows logically, using your own
example, that a far greater and more successful effort lies in
examination than in doing.
You see I want this project to succeed. I want us to use "real"
raw material, thus having reuse at the statement level. I don't
need anything with the complexities and incompatibilities of OO
technology and class libraries. Everything should be potentially
reusable, i.e. compatible. When I have to effect a source change
which impacts multiple, possibly hundreds of modules, I want it to
occur automatically and in sync throughout in software.
The tools to do this do not exist. The tools that do exist,
whether free or not, require more than a small group can develop
and maintain competitively. Microsoft sits with some 38 "billion"
dollars in cash reserves. It can afford to give Windows away for
free and still be on the plus side of the ledger. You cannot beat
Microsoft using essentially its tools or their competitive clones.
When you do you are playing its game, one you will lose as the
JAVA people will discover going up against C# and .Net.
We need to win. To win we must change the rules, force Microsoft,
IBM, and the others to play under our rules instead of, as
currently, theirs. That difference lies in the tool set, in
making "slight" shifts in current paradigms that allows a few to
do what requires many currently. I've mentioned two very
necessary ones: (1) the use of a database of source statements
with a directory of raw material (the source statements) and their
assemblies, and (2) the elimination of a compiler unit of work to
a single external procedure, allowing multiple executables to
occur from within a single compile, a single unit of work.
This last means eliminating the distinction between internal and
external procedures, thus eliminating the practice of physically
"nesting" internal procedures. This allows an unordered set of
procedures to appear as input to a single compile with the
software ordering them into a logical hierarchy of one or more
separate executables. As such we can perform the construction
stage at a system level using software to replace the major
portion of the manual effort now occurring outside software.
At some future point in our progress when we repeatedly stumble
over each other in an attempt to maintain a system as a whole we
will understand how our tools handicap us. Perhaps then we will
see the sense in modifying our tools to allow us to achieve more
through software and do less outside of it.
Re: Part 6
#169 From: "Michal Necasek" <michaln@...>
Date: Fri Feb 22, 2002 7:44 am
Subject: Re: OSFree and our future michalnec
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
On Thu, 21 Feb 2002 18:54:06 -0800 (PST), Lynn H. Maxson wrote:
I knew this was going to be fun!
>Michael Necasek writes:
>
That's Michal, not Michael, thank you.
>"That's a VERY good point. These guys got it all wrong. They think
>they can design a working kernel while sitting in an armchair.
>That is unfortunately nonsense. It doesn't work that way and there
>is one simple reason: until you implement something, you do not
>know what problems you will face."
>
>That assumes that they have never implemented anything or that no
>implementation exists. In either instance you have these
>experiences and the problems, if any, associated with them. Given
>a set of such instances recorded either in source code or source
>text allows you to return to your armchair, take advantage of
>these experiences, and move forward with confidence of your
>results.
>
That's exactly what I don't believe. Because the computing scene
is evolving far faster than you seem to realize. Experiences from
20 years ago are quite possibly completely useless today. User
requirements are changing constantly. That is the problem.
>"Some silly people compare software engineering to civil
>engineering to prove how stupid SW engineers are. They say, look,
>an engineer can build a bridge or a building without schedule
>slippages and delays and additional expenses and whatnot. If you
>SW guys can't do it, you must be doing it all wrong."
>
>Unfortunately it wasn't the civil engineers saying this. It was
>the so-called software engineers.
>
You know, it's not my fault that my business card says "software
engineer". I'd say "programmer" or "coder". But my business card
being what it is, I have to defend it
>They believed that you should
>be able to "engineer" software in the same manner you engineered
>hardware, whether a computer or a bridge. The key they felt was
>in maximising use, i.e. reuse, of components. The component they
>chose was objects, a hierarchical class arrangement of data and
>methods using messaging as intercommunication. It was the
>so-called software engineers who claimed that such capability
>would allow them to produce the same results as civil (mechanical,
>electrical, electronic) engineers.
>
I think OOP is mostly a load of bull in nice wrapping and no
better than "traditional" programming methods. Maybe I'm not
a software engineer after all?
Actually, there is a lot of good in OOP, only it's rather
difficult to separate the good stuff from the hype. And most
(all?) of the good is not really new, just repackaged.
>The difficulty, of course, lay in the differences of reusable
>components, the different levels of abstraction from raw material
>to higher level assemblies. In "real" engineering, in
>manufacturing, this is known as constructing a Bill of Material
>(BOM). The difference between a software BOM, as defined by OO
>software engineers, is that the lowest "raw material", i.e.
>component or object, is itself still an assembly. Whereas in fact
>the raw material, that from which all higher level derive and must
>decompose into, are source statements, either code or text.
>
I'm afraid you've lost me there. Maybe analogies are bad after
all.
>Basically in construction the lack of system level tools or
>processing breaks down the development process as a whole from the
>earlier stages of specification, analysis, and design and from the
>following stage of testing. That fault lies with coders,
>euphemistically known as programmers, who have no grasp of
>manufacturing, system level manufacturing, as it exists in other
>engineering arenas.
>
Yup, I'm an idiot, and proud of it!
>Until you eliminate treating an assembly, i.e. an object
>consisting of data and methods, as raw material, allow reuse only
>through a restricted form of inheritance, and allow the generation
>of multiple executables as a single unit of work from a single set
>of unordered source code, as it exists in common production and
>inventory control systems (PICS), you cannot blame the civil (or
>every other) engineers for questioning the integrity of software
>engineers.
>
Righto. Software engineering is an oxymoron. Things like TCP/IP,
e-mail, OS/2 that I'm using right now (and you too I assume) must
be some freak of nature and not really possible since they were
created by the so-called software engineers who know nothing about
writing programs. Excuse me, I just fell off my chair laughing.
>" Well, to that I say, this analogy would hold if every building,
>every bridge was considerably different from previous ones, built
>with new and unproven materials and if the builders several times
>changed their minds where the bridge was to actually stand."
>
>As long as you are willing to deny the principle of reuse, the
>heart and soul of OO technology, I have no argument. It's whole
>claimed purpose was to avoid or reduce the impact of the
>deficiencies you mention. If you do not believe in code reuse,
>say so.
>
I do not believe in code reuse as it is hyped by OOP proponents.
In real life it doesn't work. I do believe in code reuse of
modular and layered programming, in Unix style. I believe in
well defined interfaces.
> If you do not believe in the maximum reuse of code or in
>the hierarchical class system forming the basis of OO, then say
>so.
>
I do not. Hope you're not too shocked. We are in violent
agreement there.
>If you do not believe in them, then you certainly cannot
>believe in using their tools, their languages and their
>implementations of them.
>
I do not. Did I ever say I did? I hope not! What do you
think the OS/2 kernel is written in? Some OO language?
It's all plain C and assembly, not a bit of C++.
I think OOP is seriously overhyped. Obviously it's good
business for some people, but let's not go into that.
And I will also say one more thing (which I think someone
has already said before me): I do not believe in silver
bullets that will instantly solve all problems. There's
just hard work. The biggest secret is that there is no
secret.
Michal
Date: Fri Feb 22, 2002 7:44 am
Subject: Re: OSFree and our future michalnec
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
On Thu, 21 Feb 2002 18:54:06 -0800 (PST), Lynn H. Maxson wrote:
I knew this was going to be fun!
>Michael Necasek writes:
>
That's Michal, not Michael, thank you.
>"That's a VERY good point. These guys got it all wrong. They think
>they can design a working kernel while sitting in an armchair.
>That is unfortunately nonsense. It doesn't work that way and there
>is one simple reason: until you implement something, you do not
>know what problems you will face."
>
>That assumes that they have never implemented anything or that no
>implementation exists. In either instance you have these
>experiences and the problems, if any, associated with them. Given
>a set of such instances recorded either in source code or source
>text allows you to return to your armchair, take advantage of
>these experiences, and move forward with confidence of your
>results.
>
That's exactly what I don't believe. Because the computing scene
is evolving far faster than you seem to realize. Experiences from
20 years ago are quite possibly completely useless today. User
requirements are changing constantly. That is the problem.
>"Some silly people compare software engineering to civil
>engineering to prove how stupid SW engineers are. They say, look,
>an engineer can build a bridge or a building without schedule
>slippages and delays and additional expenses and whatnot. If you
>SW guys can't do it, you must be doing it all wrong."
>
>Unfortunately it wasn't the civil engineers saying this. It was
>the so-called software engineers.
>
You know, it's not my fault that my business card says "software
engineer". I'd say "programmer" or "coder". But my business card
being what it is, I have to defend it
>They believed that you should
>be able to "engineer" software in the same manner you engineered
>hardware, whether a computer or a bridge. The key they felt was
>in maximising use, i.e. reuse, of components. The component they
>chose was objects, a hierarchical class arrangement of data and
>methods using messaging as intercommunication. It was the
>so-called software engineers who claimed that such capability
>would allow them to produce the same results as civil (mechanical,
>electrical, electronic) engineers.
>
I think OOP is mostly a load of bull in nice wrapping and no
better than "traditional" programming methods. Maybe I'm not
a software engineer after all?
Actually, there is a lot of good in OOP, only it's rather
difficult to separate the good stuff from the hype. And most
(all?) of the good is not really new, just repackaged.
>The difficulty, of course, lay in the differences of reusable
>components, the different levels of abstraction from raw material
>to higher level assemblies. In "real" engineering, in
>manufacturing, this is known as constructing a Bill of Material
>(BOM). The difference between a software BOM, as defined by OO
>software engineers, is that the lowest "raw material", i.e.
>component or object, is itself still an assembly. Whereas in fact
>the raw material, that from which all higher level derive and must
>decompose into, are source statements, either code or text.
>
I'm afraid you've lost me there. Maybe analogies are bad after
all.
>Basically in construction the lack of system level tools or
>processing breaks down the development process as a whole from the
>earlier stages of specification, analysis, and design and from the
>following stage of testing. That fault lies with coders,
>euphemistically known as programmers, who have no grasp of
>manufacturing, system level manufacturing, as it exists in other
>engineering arenas.
>
Yup, I'm an idiot, and proud of it!
>Until you eliminate treating an assembly, i.e. an object
>consisting of data and methods, as raw material, allow reuse only
>through a restricted form of inheritance, and allow the generation
>of multiple executables as a single unit of work from a single set
>of unordered source code, as it exists in common production and
>inventory control systems (PICS), you cannot blame the civil (or
>every other) engineers for questioning the integrity of software
>engineers.
>
Righto. Software engineering is an oxymoron. Things like TCP/IP,
e-mail, OS/2 that I'm using right now (and you too I assume) must
be some freak of nature and not really possible since they were
created by the so-called software engineers who know nothing about
writing programs. Excuse me, I just fell off my chair laughing.
>" Well, to that I say, this analogy would hold if every building,
>every bridge was considerably different from previous ones, built
>with new and unproven materials and if the builders several times
>changed their minds where the bridge was to actually stand."
>
>As long as you are willing to deny the principle of reuse, the
>heart and soul of OO technology, I have no argument. It's whole
>claimed purpose was to avoid or reduce the impact of the
>deficiencies you mention. If you do not believe in code reuse,
>say so.
>
I do not believe in code reuse as it is hyped by OOP proponents.
In real life it doesn't work. I do believe in code reuse of
modular and layered programming, in Unix style. I believe in
well defined interfaces.
> If you do not believe in the maximum reuse of code or in
>the hierarchical class system forming the basis of OO, then say
>so.
>
I do not. Hope you're not too shocked. We are in violent
agreement there.
>If you do not believe in them, then you certainly cannot
>believe in using their tools, their languages and their
>implementations of them.
>
I do not. Did I ever say I did? I hope not! What do you
think the OS/2 kernel is written in? Some OO language?
It's all plain C and assembly, not a bit of C++.
I think OOP is seriously overhyped. Obviously it's good
business for some people, but let's not go into that.
And I will also say one more thing (which I think someone
has already said before me): I do not believe in silver
bullets that will instantly solve all problems. There's
just hard work. The biggest secret is that there is no
secret.
Michal
Re: Part 6
#170 From: Herwig Bauernfeind <herwig.bauernfeind@...>
Date: Fri Feb 22, 2002 10:10 am
Subject: Re: osFree/CMD taxwarriorfr...
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
> >JMA schrieb:
> >> Are you able to sign up for developing an app ?
> >No, sorry, I don't speak C, only REXX and (a little) Pascal.
> How about dooing some HTML pages for the site on os2world.com ??
Sorry, I don't speak HTML either (I wish I would).
I can create .INF style manuals and I could paint icons, create REXX scripts.
Not too useful by now...
But if required, I 'll be listening on the list.
Herwig
--
+---------------------------------------------------
| Mag. Herwig Bauernfeind - Dfb. J.Bfd. - Accountant
| Martin-Luther-Str.12, A-9300 St.Veit/Glan, Austria
| Telefon: ++43 4212 2028 Telefax: ++43 4212 2028 76
| herwig.bauernfeind@... - Fidonet: 2:313/41.5
Date: Fri Feb 22, 2002 10:10 am
Subject: Re: osFree/CMD taxwarriorfr...
Offline Offline
Send Email Send Email
Invite to Yahoo! 360° Invite to Yahoo! 360°
> >JMA schrieb:
> >> Are you able to sign up for developing an app ?
> >No, sorry, I don't speak C, only REXX and (a little) Pascal.
> How about dooing some HTML pages for the site on os2world.com ??
Sorry, I don't speak HTML either (I wish I would).
I can create .INF style manuals and I could paint icons, create REXX scripts.
Not too useful by now...
But if required, I 'll be listening on the list.
Herwig
--
+---------------------------------------------------
| Mag. Herwig Bauernfeind - Dfb. J.Bfd. - Accountant
| Martin-Luther-Str.12, A-9300 St.Veit/Glan, Austria
| Telefon: ++43 4212 2028 Telefax: ++43 4212 2028 76
| herwig.bauernfeind@... - Fidonet: 2:313/41.5