I already know that what I am about to ramble on about is not very
likely, perhaps completely impossible. Still, it is worth re-interating
every once in a while. Especially since by not providing quick updates
to their client software they are telling us not to upgrade or patch
some systems...
There is a point that even if the client s/w (software) was completely
available in source form (at least the UNIX one) to the public at large
it would be completely useless without the server, which is _not_ free
and you would need to be able to use the client s/w anyway. This point
should be thought about. Then, why not make the client tools, utilities,
daemons, etc (or at least some small fraction) o/s'ed (open-sourced).
There are great reasons to do that, and bad reasons for not. If they
o/s'ed some select pieces then the o/s community would probably do alot
of good to the code (cleanup, optimization and feature additions) that
would allow Veritas to leverage free s/w development into their product.
My experience is that pre-o/s'ed s/w is much dirtier and harder to
maintain than o/s'ed s/w. Also, the number of bugs fixes and features
could be _very_ worthwhile.
There are several changes I'd like to make to parts of the UNIX 'bp'
menu, and bpcd, bpmount and bpbkar as well. Also, Veritas does not act
very fast in regards to simple library changes in OS upgrades. It really
is too bad that select parts of the client are not o/s'ed. Sure, I
understand that veritas needs mo'ney. Yet, you really need the rest of
the s/w to make it work anyway, so why not o/s parts of it that may need
to be re-built frequently (like bp) when some linked libraries change
from version to version (like glibc, or libncurses).
For example of some feature additions, 'bp' needs a way to select a set
of files and directories in one fell swoop. Or, the MacOSX 'bundle bit'
is not taken into account when doing incrementals, thus catching
thousands of extra files that actually should not be being backed up
each day. That needs to be fixed. The include and exclude files need to
be able to be used together more powerfully. If I exclude '/' and
.snapshot and I include /remote_mount1 (which has a .snapshot), I want
backups to not back up those files or junk directories. Perhaps use real
REGEX. These are simple improvements that still have not been made,
though comments and suggestions through other channels.
The practical effect by not o/s'ing the client sides is to tell the
marketplace that you need another backup software for 'new' (and
possibly 'patched') systems and that Veritas NBU cannot be used,
assuming that Veritas continues to be slow to get updated client s/w out
to folks. This is not a good statement to make. When MacOS 10.1 became
10.2, suddenly folks could not use the 'bp' command. That Mac 10.2
upgrade was only a minor change (and mostly for security patch
reasons...like the openssh issue), yet requires a whole new NBU client?
Linux 8 and 9 are only really slightly different, too, along the same
lines. The point is is that if Veritas cannot quickly get the client s/w
out to folks when something changes, the situation becomes quite
impossible for some group of people. I just cannot tell someone to NOT
apply security patches to their system. I just _cannot_ do that, and no
one should be forced to not update their systems with patches. Nor can I
tell a developer that if he upgrades to RedHat 9 he will no longer be
able to be backed up (or at least do restores with 'bp'). So, we still
have other backup software for these systems that is not NBU. Is that
not a tragic waste of money to need 2 s/w's to backup old and new clients?
These opinions are soley mine. Flame if you will (though I can't
unerstand why one would...). :-)
Ciao!
Chris
>Incorrectly built binary which accesses errno, h_errno or _res directly.
>Needs to be fixed.
>
>
Example of a SECURITY improvement that needs quick attention in
re-compiling the software!
You know, there may be a few buffer overflows to certain commands. I
have seen bpcd dump core once. I wonder if I can bust root with some
clever buff overflow attack against some client commands. Hmmm. Might be
FUN! I'll post more on that if I check into it.
|
