SCOUG Logo


Next Meeting: Sat, TBD
Meeting Directions


Be a Member
Join SCOUG

Navigation:


Help with Searching

20 Most Recent Documents
Search Archives
Index by date, title, author, category.


Features:

Mr. Know-It-All
Ink
Download!










SCOUG:

Home

Email Lists

SIGs (Internet, General Interest, Programming, Network, more..)

Online Chats

Business

Past Presentations

Credits

Submissions

Contact SCOUG

Copyright SCOUG



warp expowest
Pictures from Sept. 1999

The views expressed in articles on this site are those of their authors.

warptech
SCOUG was there!


Copyright 1998-2024, Southern California OS/2 User Group. ALL RIGHTS RESERVED.

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.

The Southern California OS/2 User Group
USA

SCOUG-Programming Mailing List Archives

Return to [ 17 | July | 2003 ]

>> Next Message >>


Date: Thu, 17 Jul 2003 07:57:30 PDT7
From: "Lynn H. Maxson" <lmaxson@pacbell.net >
Reply-To: scoug-programming@scoug.com
To: < "scoug-programming@scoug.com" > scoug-programming@scoug.com >
Subject: SCOUG-Programming: button challenged

Content Type: text/plain

Peter,

I've never considered that reformulating a process of existing
technology based on an existing method of doing so as
theoretical design. I guess until it's completed it remains
theoretical. Of course the same applies to all software
development and maintenance. That puts me in good
company with you, Steven, Mark, and Linus Torvalds.

Admittedly I've focused not on what software does, but on
finding easier, more affordable ways of getting it to do it.
You bring up to aspects, one related to versioning and the
other related to an "enhanced" help facility. Let's take the
second first, and the first second.

Your enhanced help facility comes builtin to all fourth
generation languages including AI and neural nets, in fact all
of logic programming. It comes as a byproduct of the first
proof, the completeness proof, of the two-stage proof engine.
In the parlance it's called backtracking, taking you from the
final cause-effect result of a sequence (or path) of such
processes "back" through and to the initial set. Thus it is part
and parcel of what I have been proposing.

It's not a leap of faith to see that any software update is a
new version, actually more accurately a different version.
Open source says it can occur from a change that you make
or that others have. Any one or combinations of such changes
create a different version, which because it occurs after an
existing one is a new one.

As others have pointed out in this thread some software
already supports a restricted form of automated update. In
fact the fixpaks of OS/2 offer a more protective form in that it
also supports return from a newer version to the previous.

The difficulty here, as they say, lies in the details or more
specifically to their absence. Any source change represents a
new version as does any set of such changes. The question
then becomes one of control that you have over the level of
change. Does that control reside with you or with someone
else? And at what level of detail?

From my perspective you only seek a partial solution, one
which respects externally (third party) specified boundaries of
a specific software package. You do not consider that
boundaries themselves are arbitrary, that you can have
different subsets, i.e. combinations, of its functions or you can
combine them with those of other software. You see, one of
the beauties of open source lies in enabling you to determine
(control) the packaging, i.e. the boundaries.

You may very well opt to allow third-parties to make those
choices. In doing so you become dependent upon their doing
so. In the instance of IBM and OS/2 and all the ISPs that have
since declined to continue to do so I would think you more
receptive to the idea of a system that allows you and your
similarly inclined friends to do it for yourselves, part of the
philosophical basis for open source.

Thus I see no reason for an update button per se as much as I
see a further purpose in a source maintenance system which
offers you a choice of versions from the change of a single
statement on up. That allows you to determine what changes
you want and those you do not plus the ability to return to
where you started or to an even earlier point.

Closed source, the dependence on third parties, does not offer
you that choice. Unless they choose to do so they need not
offer you an update at all. They also determine which are
free and which are fee. Open source at least offers you the
option of dependence on third parties with the further option
of reducing said dependence.

I would suggest that you forego the "update" button in favor
of a system that allows you to "see" not only your version but
all versions. It would allow you not only to select from among
them but the selection process itself would allow you to add
to the versions available.

You want to "query" a system to determine if newer version
exists. That's what you want when you want the choice to
update or not. I assume if there is more than one, you want
the ability to select which. I further assume that if you find a
version of another "package" which incorporates yours that
you would want the option of selecting it.

If so, what you want is a system with version control that
offers you the ability to pick and choose with boundaries more
aligned with your needs. If finding none, then allows you to
create one of your own.

That, my friend, is open source. Unfortunately its promise
remains in your terms a "theoretical design". I'm working to
remove it from that category. Unfortunately until the
work is complete, until that version exists, it remains a
theoretical design. Ah, the curse of all software.

=====================================================

To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-programming".

For problems, contact the list owner at
"rollin@scoug.com".

=====================================================


>> Next Message >>

Return to [ 17 | July | 2003 ]



The Southern California OS/2 User Group
P.O. Box 26904
Santa Ana, CA 92799-6904, USA

Copyright 2001 the Southern California OS/2 User Group. ALL RIGHTS RESERVED.

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.