latest argus?

[Tim Lavoie]

>>>>> "CB" == Carter Bullard <carter at qosient.com> writes:

    CB> Hey Tim, There are really hundreds of these types of packages,
    CB> and each has its benefits.  If we were to open it up, I'd be
    CB> willing to bet that .Net would get some votes, and although
    CB> its not a bad system at all, it really can't be a candidate,
    CB> for obvious reasons.

    CB> But source code control and package distribution strategies
    CB> should be in the same discussion, in a lot of ways, because
    CB> our source code control scheme is also our product
    CB> distribution strategy.  So I would also like to understand how
    CB> to provide a good distribution mechanism for users of the code
    CB> as well as source.

    CB> Is this something that is well developed and understood in the
    CB> real world?  Autoupdates?  Something like redhat network, or
    CB> perl's cpan.  Do we need to do something in the code to
    CB> facilitate these types of strategies?  Probably, simple stuff
    CB> like version numbering schemes is more important that other
    CB> things.

    CB> I have not researched this at all, but it is something that is
    CB> interesting.  Sorry to hijack your response, but I am
    CB> interested in picking a strategy that has a good bang for its
    CB> bucks, so to speak.

    CB> What do you think?


Hi Carter,

Your questions are certainly good ones, and I do like the idea of
integrated distribution of source and packages.

I think the problem has been solved before, plenty of times. That's part
of the problem too though, in that each solution is somewhat
different, and mostly incompatible. I use Debian at home, and Red Hat
at work; others will have different Linux distros, or something
entirely different.

Most of these systems work from the OS on down, and are fine for that
intent. If I understand correctly, you would like to poll from the
application, so whatever you do should be portable, or at least query
for something that matches the OS it is currently running on. From
that sense though, would it update everything (including itself), or
is there some overall shell that replaces parts of itself? In the
latter case, I'm thinking (for example) of TCL apps which can keep
code in a virtual fileystem. It can query back home for updates, if
that's what you want. TCL Starkits are portable, but can contain
OS-specific modules within them. There's a good paper on that, at:
http://www.equi4.com/papers/skpaper1.html

CPAN works in that what it distributes is portable as far as running
with compiled Perl binaries on different systems. If you can do
something similar, it would save the effort of maintaining and posting
multiple binary versions. Oh, and I'd like to suggest some sort of
authentication for the server side in any update scheme. For example,
Debian packages can have GPG signatures, which the update tools can
check. You wouldn't want someone to attack Argus by trying to point to
a trojan update server.

Whoops, I'm rambling. Time to get back to work.   :)

	Cheers,
	Tim