[openbeos] Re: general update tool idea

  • From: "Erik Jaesler" <erik@xxxxxxxxxxxxxx>
  • To: openbeos@xxxxxxxxxxxxx
  • Date: Wed, 19 Jun 2002 12:57:56 -0700

>What I would feel is that CVS is more of a developer's tool than a
>normal user tool.

Of course.  And bleeding-edge builds are more for developers than normal 
users. ;)

>What users might want is an update system, maybe a notification that
>there is an update. Take a look at windows "update notification"
>system. They notify you of any updates to the OS, direct you to their
>website, and shows you all the updates, patches, etc. and of course
>the user get to use which to download and update, and that's all.

An update system like Windows has is one thing (and potentially a good 
thing for users), but what has been proposed is a system whereby 
individual object files (intermediate files generated by the compiler 
then linked together into the actual app) can be downloaded and the 
target application re-linked on the user's system.  Of course, this 
requires a server which is actually *building* those intermediate files 
so that they're available.

While this is an interesting idea, and I certainly encourage the person 
who proposed it to try and implement the system to see how useful it 
actually is, it seems to me that it has the potential to get uninformed 
users (i.e., those that don't know how to use cvs and jam) into a great 
deal of trouble.  The point being that developers are generally aware of 
the risks they're taking by using the latest and (often) not so great 
source on their system and, more importantly, how to recover from any 
resulting catastrophes.  Of course, there are non-developer users who 
are savvy enough to effect that sort of recovery, but all in all, it 
seems like this system would just be asking for trouble.

As an aside, if you're looking to truly be on the bleeding-edge, you 
can't get much closer than actually using cvs and jam -- and, 
incidentally, this is not going to be much more band-width intensive 
that the system being proposed.  You're retrieving text source files 
(which can be heavily compressed), only compiling what is out of date 
and then linking.  Really very little additional overhead.


>I think that is quite good, well integrated into the OS, somewhat
>irritating, but the new version handles updates much more gracefully,
>giving you the options to notify you when there is an update, to
>download first then notify you, or do not update at all (i can't
>remember all of them at hand). Whatever they are, it saves the user
>to search the website and explicitly search for updates.
>Justin Lee
>On Wed, 19 Jun 2002 21:08:41 +0200, Linus Almstrom wrote:
>>I can understand the reason for having a gui app for users
>>that are not familiar with a shell, but constructing a new
>>system for which cvs is well suited I cannot understand.
>>I'd rather see a gui for cvs/make which would use less
>>bandwidth than the semi-binary approach, but both systems
>>will ofcourse be possible to have side by side.
>>The only real benefit from the semi-binary system, as I
>>see it, is that it does not need to rely on either
>>Jam or make, which ofcourse is a nice benfit GUI-wise.

Necessity is the plea for every infringement of human freedom. It is the 
argument of tyrants; it is the creed of slaves.
        -William Pitt, British prime-minister (1759-1806)

Other related posts: