Quote:

Quote:

I use an old version


Good for you. So then why are you complaining? You want the features of the latest version but don't want to pay for it?

You are obsessing over size. 200k is peanuts related to what else goes up and down the pipe. Like Shawn said, copy it to the client if you are so concerned.

I have single spreadsheets that add up to more that what your DC transfers in an entire day and I am not obsessing.



Sounds like both of you live by the idea that if you have extra bandwith you might as well use it.
Why no interest in optimization? If I can grab a executable compression application found on google in 5 seconds and reduce the file size by 60% that leads me to believe more could be done in development.

All of this adds up to the time the user spends waiting for his machine. In the end 5 seconds here and there may not sound like much but if you can reduce the wait time 15 seconds overall (trying to optimize in any way you can) and multiply that by the number of employees, the number of work days and the average salary you just saved a good chunk of change!

Oh and to give you an idea quickly, I do have extremely fat pipes to the machines on the network. Ill share with you because Im proud of it

Users are connected to a group of Cisco 4507 in every area with dual sup and 5 ws-x4548-gb cards. Thats 10/100/1000 to the desktop (and many machines have gigabit nics). Those are dual fiber attached to two 6513. The servers are dual connected to ws-6748-ge in the 6513s which have sup 720s, dual copper load balanced GB connections to most of the servers.

I understand that additional features need an increase in file size. What I cant see is such a large increase that relate to a few useful features and a few more less often used features.

I propose not only getting the main kix32 executable file size smaller in some way but also the possibility of a "light" version geared towards the most common used commands!

Edited by ciper (2004-11-03 02:40 AM)