On 27/11/2018 22:28, Carlos E. R. wrote:
Thanks! Very interesting :-)
You're very welcome. This was one of those things that for a long time I just assumed everyone knew... then it has become apparent in the last ~dozen years (since Vista) that apparently lots of people _didn't_ know, and indeed, that this lack of knowledge was percolating up the chain. The time it hit me personally was upgrading a customer's installation of MS Office XP to SR1. This was so big, for the time -- several hundred megabytes, zipped, in 2002 and thus before many people had broadband -- that optionally you could request it on CD. He did. The CD contained a self-extracting Zip that extracted into the current directory. So you couldn't run it directly from the CD. It was necessary to copy it to the hard disk, temporarily wasting ¼ GB or so, /then/ run it. The uncompressed files would have fitted on the CD. That was a warning sign; several people failed in attention to detail and checks. (Think this doesn't matter? The tutorial for Docker instructs you to install a compiler, then build a copy of MongoDB (IIRC) from source. It leaves the compiler and the sources in the resulting container. This is the exact same sort of lack of attention to detail. Deploying that container would waste a gigabyte or so per instance, and thus waste space, energy, machine time, and cause over-spend on cloud resources. All because some people just didn't think. They didn't do their job well enough. So, I copied the self-extractor, I ran it, and I started the installation. A progress bar slowly crept up to 100%. It took about 5-10 minutes. The client and I watched. When it got to 100%... it went straight back to zero and started again. This is my point: progress bars are actually quite difficult. It did this SEVEN TIMES. The installation of a service release took about 45 minutes, three-quarters of an hour, plus the 10 minutes wasted because an idiot put a completely unnecessary download-only SEA onto optical media. The client paid his bill, but unhappily, because he'd watched *me* wasting a lot of expensive time because Microsoft was incompetent at: [1] Packaging a service pack properly. [2] Putting it onto read-only media properly. [3] Displaying a progress bar properly. Of course it would have been much easier and simpler to just distribute a fresh copy of Office, but that would have made piracy easier than this product is proprietary software and one of Microsoft's main revenue-earners, so it's understandable that they didn't want to do that. But if the installer had just said: Installation stage x/7: Progress: [XXXXXXXXXX..........] That would have been fine. But it didn't. It went from 0 to 100%, seven times over, probably because first the Word team's patch was installed, then the Excel team's patch, then the Powerpoint team's patch, then the Outlook team's patch, then the Access team's patch, then the file import/export filters team's patch, etc. etc. Poor management. Poor attention to detail. Lack of thought. Lack of planning. Major lack of integration and overview. But this was just a service release. Those are unplanned; if the apps had been developed and tested better, in a language immune to buffer overflows and which didn't permit pointer arithmetic and so on, it would have have been necessary. But the Windows Vista copy dialog box, as parodied in XKCD -- that's taking orders from poorly-trained management who don't understand the issues, because someone didn't think it through or explain it, or because someone got promoted to a level they were incompetent for. https://en.wikipedia.org/wiki/Peter_principle These are systemic problems. Good high-level management can prevent them. Open communications, where someone junior can point out issues to someone senior without fear of being disciplined or dismissed, can help. But many companies lack this. I don't know yet if SUSE has sorted these issues. I can confirm from bitter personal experience that Red Hat suffers badly from them.
Some software gives an estimate which is constantly adjusted. In the end, it matches ;-)
(yast install does that ;-P )
OK. Another answer is to concede that the problem is hard, and display a "throbber" instead: show an animated widget that shows something is happening, but not how far along it is. That's what the Microsoft apps team often does now. Personally, I hate it. It's better than nothing but it conveys no useful information.
It may give an estimate of the maximum time needed, after it does the scanning of files and it knows how many files to try copy. This could be adjusted after some time copying files and calculating an average. There are of course many variables: time to do the compare, time to do the crc check (if requested or needed), time to do the copy...
I'd prefer an indicator that says "stage 6 of 15, copying file 475 of 13,615." I may not know which files are big or small, which stages will be quick or slow... but I can see what it's doing, I can make an approximate estimate in my head, and if it's inaccurate, well, I can blame myself and not the developer. And nobody has to try to work out what percent of an /n/ stage process with /o/ files of /p/ different sizes they're at. That's hard for someone to work out, and it's possible that someone can't tell them a correct number of files or something... so you can get progress bars that go to 87% and then suddenly end, or that go to 106%, or that go to 42% and then sit there for an hour, and then do the rest in 2 seconds. I'm sure we've all seen all of those. I certainly have. -- Liam Proven - Technical Writer, SUSE Linux s.r.o. Corso II, Křižíkova 148/34, 186-00 Praha 8 - Karlín, Czechia Email: lproven@suse.com - Office telephone: +420 284 241 084 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org