I am truly frustrated at applications like online update, open suse update, Zen, what ever you like enforcing the application set standards on an acceptable response time from the update source.
When are we going to stop dictating to the comms
protocols, which are far more superior in making
decisions, perform retries and have all the redundancy
built in. - That why we have comms protocols - To work
out all that stuff.
Now we have various online update sources impose their
time limits upon over and above what comms is designed
to perform.
I know there have been so may changes to online update
for various reasons and I would issue extreme caution
here in the people who are playing with absolute values
for comms traffic over and above what it does best
left alone.
I want to see the total removal of all limiting factors
zen updater imposes on comms right now. You never have
an application decide on retries, redundancy issues,
etc. ALL these factors are part of comms and the issue
here is comms tries relentlessly to obtain a valid and
intact packets from source and it will continue to use
every means at its disposal - This is why we have such
sophistication in our comms protocol.
I would like to know WHY YAST2 imposes its own set of
values to comms. This is the wrong way round - comms
frailties are generally looked after by itself and will
ultimately issue error responses at the last resort. We
do not need application imposed values on a comms
protocol.
If we don't remove all application imposed limitations
on comms traffic, AND stop playing with it we ALL we
reach a stage where it will be impossible to correct
the damage we may send out in a successful update to YAST2.
For every single failure of an online update I would
like a BUG report raised. We all do not have T3 comms
lines that testing is done on at suse.de. at best I
have a very fast 20/10 mb per sec and I still get error
after error from Yast2 giving up and telling comms to
give up on a online update as the redundancy imposed
parameters by YAST2 are in conflict with the redundancy
abilities of the protocol.
Go back to the 10.0 suse updater, eradicate zen
updater, eradicate open suse updater and leave comms
alone to do what it does best. We have been trying to
get online update working since the rubbish started
poring out since 10.1 and it continues to get worse not
better. OMG could you image M$ not being able to update
its own M$ Windows an M$ Vista O/S. Has anyone ever
heard of M$ online update fail. If M$ can distribute
SP2 for XP which was in excess of 100mb of data without
issue to a very large audience world wide; why the hell
are we still struggling to update several small files
to an infinitely smaller audience.
If Novell can product such a sophisticated advanced
file server in Netware then where are all those cleaver
minds today - Certainly they are NOT at suse.de
smime.p7s
Description: S/MIME Cryptographic Signature
