Modified installation progress
Challenge: ---------- Libzypp supports parallel download and install. Yast installation progress does not fit it at all [1]. Issues are secondary progress bar that does not work with parallel installation. Also there are overwhelming amount of information on screen that is quite distracting. That information is often wrong like time estimation. And also table for media is a bit useless nowadays as everything is on one iso/medium, so there is no need to see when cd switch will be needed. The details tab are the most visible as it is default one. Proposal: --------- Remove completely that details tab and keep just release notes one[2]. It contains release notes that contain useful information and also has just one progress bar. For that bar remove keep always just remaining size and count of packages, so user has idea how it does, but do not print what exactly is installing or any time estimation. If there are more release notes allow to switch between them. Also keep possibility to have slide show which we had in past for installation if someone create some ( when checked other OSes, the Ubuntu slide show during installation looks probably the best from user POV ). The same changes will apply to ncurses front end[3], we just need to check why formatting of release notes are so badly formatted. And same for opensuse[4] of course. Josef [1] https://pasteboard.co/cNBjER6SnLLT.png [2] https://pasteboard.co/WnI7wS7VVVqq.png [3] https://pasteboard.co/vzQvY1PaVDaD.png [4] https://pasteboard.co/FzEqcIN7Xnas.png
On 2021-11-04 11:14, josef Reidinger wrote:
Challenge: ----------
Libzypp supports parallel download and install. Yast installation progress does not fit it at all [1]. Issues are secondary progress bar that does not work with parallel installation. Also there are overwhelming amount of information on screen that is quite distracting. That information is often wrong like time estimation. And also table for media is a bit useless nowadays as everything is on one iso/medium, so there is no need to see when cd switch will be needed. The details tab are the most visible as it is default one.
Proposal: ---------
Remove completely that details tab and keep just release notes one[2].
Yikes. That will make tracking down problems completely impossible; for us as well as for users. This is not a good idea IMHO. As a user, I want to get a general idea what's going on. More often than not, it's some specific packages that take forever to install; some post-install script building a kernel module, for example. Not having any information about that is a huge step backwards IMHO.
It contains release notes that contain useful information
For some, maybe. Certainly not for everybody.
and also has just one progress bar. For that bar remove keep always just remaining size and count of packages, so user has idea how it does,
That is much too coarse IMHO.
but do not print what exactly is installing or any time estimation. If there are more release notes allow to switch between them.
Also keep possibility to have slide show which we had in past for installation if someone create some
That slideshow seemed like a good idea back in the early 2000s. We had intended it to show highlights of the distribution that you are currently installing, to entertain the users (who were installing from CDs or DVDs back then which took a looong time) and to give them a good feeling about their new system that they were currently installing. It took about 7 nanoseconds until that was hijacked by marketing who misused it to show the user the OTHER products, more or less implying "duh, you got the wrong one". The idea and spirit behind the slideshow were dead at that moment, yet we were saddled with that over-complicated code. We had to make it over-complicated because of limitations that we had back then with YCP and the overall YaST engine; but even today it wouldn't become significantly easier, clearer or better to maintain. IMHO this is the best opportunity to get rid of that slideshow for good. It has been in zombie state for many years, yet it was always in the way. I propose we could do something similar to what we (Knut and I) did recently for formatting DASDs: - One progress bar because that's really the best thing we can do - Provide a list or several lists of packages - currently being installed - finished installing - waiting to be installed along with the number in each category, of course. The DASDformat prototype: https://github.com/shundhammer/dasdfmt-proto/issues/2 the package installation would look differently, of course; but you can get some inspirations from here. I'll happily help with more detailed UI design, but please let's not dumb this down to the point of becoming useless; and by all means let's get rid of that slideshow code monster. Nobody asked for it for at least the past 6 years (probably even for the last 10-12 years); let's bury that thing for good. Kind regards -- Stefan Hundhammer <shundhammer@suse.de> YaST Developer SUSE Software Solutions Germany GmbH GF: Ivo Totev; HRB 36809, AG Nürnberg
El jue, 04-11-2021 a las 13:58 +0100, shundhammer escribió: [..]
Yikes. That will make tracking down problems completely impossible; for us as well as for users. This is not a good idea IMHO. As a user, I want to get a general idea what's going on. More often than not, it's some specific packages that take forever to install; some post-install script building a kernel module, for example.
Not having any information about that is a huge step backwards IMHO.
To be honest, usually that information goes too fast, so it is nearly impossible for me to find something useful there. And, if something goes wrong, I would expect YaST to notify me about the problem.
It contains release notes that contain useful information
For some, maybe. Certainly not for everybody.
I usually find release notes quite useful. If release notes are informative and well-written, and think it might be a good idea.
and also has just one progress bar. For that bar remove keep always just remaining size and count of packages, so user has idea how it does,
That is much too coarse IMHO.
+1 to Josef proposal. We could add "remaining time" information but only if it is kind of accurate. If it is going from 5 minutes, to half and hour to 1 minute again, then it is better not to show anything.
IMHO this is the best opportunity to get rid of that slideshow for good. It has been in zombie state for many years, yet it was always in the way.
Yes, please, let's get rid of it.
[..]
Thinking a little bit further, would it make sense to unify the packages installation progress and the finish clients screen into a single one? After all, we could display a message below the progress bar ("installing packages", "installing the bootloader", etc.). What do you think? Regards, Imo -- Imobach González Sosa YaST Team at SUSE LLC https://imobachgs.github.io/
On 04.11.21, 14:24, "Imobach Gonzalez Sosa" <IGonzalezSosa@suse.com<mailto:IGonzalezSosa@suse.com>> wrote: El jue, 04-11-2021 a las 13:58 +0100, shundhammer escribió: [..] Yikes. That will make tracking down problems completely impossible; for us as well as for users. This is not a good idea IMHO. As a user, I want to get a general idea what's going on. More often than not, it's some specific packages that take forever to install; some post-install script building a kernel module, for example. Not having any information about that is a huge step backwards IMHO. To be honest, usually that information goes too fast, so it is nearly impossible for me to find something useful there. And, if something goes wrong, I would expect YaST to notify me about the problem.
It contains release notes that contain useful information
For some, maybe. Certainly not for everybody. I usually find release notes quite useful. If release notes are informative and well-written, and think it might be a good idea.
and also has just one progress bar. For that bar remove keep always just remaining size and count of packages, so user has idea how it does,
That is much too coarse IMHO. +1 to Josef proposal. We could add "remaining time" information but only if it is kind of accurate. If it is going from 5 minutes, to half and hour to 1 minute again, then it is better not to show anything. IMHO this is the best opportunity to get rid of that slideshow for good. It has been in zombie state for many years, yet it was always in the way. Yes, please, let's get rid of it. [..] Thinking a little bit further, would it make sense to unify the packages installation progress and the finish clients screen into a single one? After all, we could display a message below the progress bar ("installing packages", "installing the bootloader", etc.). What do you think? I think that the real use-cases are: 1) to know that the installer is still doing something and not dead. 2) to know how far along the installer is, and how much is left Maybe showing a percentage and the current main steps (as Imo suggest above) would be better? The real problem is that we cannot guess how long the whole thing takes. Currently we are providing every possible detail to somehow fill that gap and I don’t think it’s making anything better, but rather worse. -- Ken
On 2021-11-04 14:35, Kenneth Wimer wrote:
I think that the real use-cases are:
1) to know that the installer is still doing something and not dead.
Right. And you can only find that out if something is moving; if it's ONLY a progress bar for the overall progress, you won't see much movement, especially if you have such pathological cases like long actions performed in some post-install script: Generating fonts, building a kernel module, downloading files from a very busy server (case in point: fetching MS true type fonts).
2) to know how far along the installer is, and how much is left
Right.
Maybe showing a percentage and the current main steps (as Imo suggest above) would be better?
That will of course always be done in parallel.
The real problem is that we cannot guess how long the whole thing takes.
Exactly; and a parallel installation will make that much worse since many things (downloads, installing packages) will be done in parallel, so that overall progress will be very rough; we can basically only rely on how many packages (out of how many) are completely installed (which includes the download, of course) yet.
Currently we are providing every possible detail to somehow fill that gap and I don’t think it’s making anything better, but rather worse.
No, we are not providing every possible detail; we are giving a pretty coarse overview: We only display what package is being installed right now, and the history of previous packages is scrolling by. But that latter part is mostly to keep the user entertained; and to give him a chance to read the last few entries if the message is replaced too quickly with a new one. Kind regards -- Stefan Hundhammer <shundhammer@suse.de> YaST Developer SUSE Software Solutions Germany GmbH GF: Ivo Totev; HRB 36809, AG Nürnberg
On 11/4/21 13:24, Imobach Gonzalez Sosa wrote:
Thinking a little bit further, would it make sense to unify the packages installation progress and the finish clients screen into a single one? After all, we could display a message below the progress bar ("installing packages", "installing the bootloader", etc.).
What do you think?
I like the idea. Sorry for the "art" work ;) |--------------------------------------- | RELEASE NOTES | | | |Installing Packages (Remaining: 1.5 GiB, 123/850 packages) | [******-----------20%-----------------] | |------------------------------------ |--------------------------------------- | RELEASE NOTES | | | |Installing Bootloader | [******************************95%---] | |------------------------------------ -- José Iván López González YaST Team at SUSE LINUX GmbH IRC: jilopez
On Thu, 4 Nov 2021 16:10:34 +0000 José Iván López González <jlopez@suse.de> wrote:
On 11/4/21 13:24, Imobach Gonzalez Sosa wrote:
Thinking a little bit further, would it make sense to unify the packages installation progress and the finish clients screen into a single one? After all, we could display a message below the progress bar ("installing packages", "installing the bootloader", etc.).
What do you think?
I like the idea. Sorry for the "art" work ;)
Nice art work ;) But not needed, as it already works this way. first 10% is disk preparation ( partitioning, files deployment before rpm install, etc. ), then 80% is package installation including post rpm scripts and the last 10% is finish client. It is done by a bit tricky way that all clients share state of Yast::Progress. If you are interesting in finish client this method handle it ( it sets slideshow only if not already set ) https://github.com/yast/yast-installation/blob/master/src/lib/installation/c... But it brings interesting observation that even people that do regularly testing installation does not see it :) So for me it is indication that only progress that does not move brings some attention :) Josef
|--------------------------------------- | RELEASE NOTES | | | |Installing Packages (Remaining: 1.5 GiB, 123/850 packages) | [******-----------20%-----------------] | |------------------------------------
|--------------------------------------- | RELEASE NOTES | | | |Installing Bootloader | [******************************95%---] | |------------------------------------
On Thu, 2021-11-04 at 16:10 +0000, José Iván López González wrote:
On 11/4/21 13:24, Imobach Gonzalez Sosa wrote:
Thinking a little bit further, would it make sense to unify the packages installation progress and the finish clients screen into a single one? After all, we could display a message below the progress bar ("installing packages", "installing the bootloader", etc.).
What do you think?
I like the idea.
I like it too. As a user, those details have been never useful to me. Perhaps we can offer a "Show details" option for those who are interested to see in detail what's going on. I think Ubuntu and others already do it with a collapsible widget. Deepin[1][2] does it by interchanging the slider with the expert output (aka log). If I'm not wrong, we don't have a special widget for it, but we can use a :ReplacePoint. Just a way to offer all options, but with a focus on the simpler (and probably most useful) one. Yet another option ;) [1] https://paste.opensuse.org/0a1fadae [2] https://paste.opensuse.org/3e503d61
Sorry for the "art" work ;)
--------------------------------------- RELEASE NOTES
Installing Packages (Remaining: 1.5 GiB, 123/850 packages) [******-----------20%-----------------]
------------------------------------
--------------------------------------- RELEASE NOTES
Installing Bootloader [******************************95%---]
------------------------------------
-- José Iván López González YaST Team at SUSE LINUX GmbH IRC: jilopez
-- -- David Díaz YaST Team at SUSE LINUX GmbH IRC: dgdavid
On Fri, 2021-11-05 at 10:30 +0000, David Díaz wrote:
On Thu, 2021-11-04 at 16:10 +0000, José Iván López González wrote:
On 11/4/21 13:24, Imobach Gonzalez Sosa wrote:
Thinking a little bit further, would it make sense to unify the packages installation progress and the finish clients screen into a single one? After all, we could display a message below the progress bar ("installing packages", "installing the bootloader", etc.).
What do you think?
I like the idea.
I like it too. As a user, those details have been never useful to me.
Perhaps we can offer a "Show details" option for those who are interested to see in detail what's going on. I think Ubuntu and others already do it with a collapsible widget. Deepin[1][2] does it by interchanging the slider with the expert output (aka log).
Althought I like more how it is presented in elementary OS [1][2] [1] https://paste.opensuse.org/2dfde486 [2] https://paste.opensuse.org/ea0a54b9
If I'm not wrong, we don't have a special widget for it, but we can use a :ReplacePoint. Just a way to offer all options, but with a focus on the simpler (and probably most useful) one.
Yet another option ;)
[1] https://paste.opensuse.org/0a1fadae [2] https://paste.opensuse.org/3e503d61
Sorry for the "art" work ;)
--------------------------------------- RELEASE NOTES
Installing Packages (Remaining: 1.5 GiB, 123/850 packages) [******-----------20%-----------------]
------------------------------------
--------------------------------------- RELEASE NOTES
Installing Bootloader [******************************95%---]
------------------------------------
-- José Iván López González YaST Team at SUSE LINUX GmbH IRC: jilopez
-- -- David Díaz YaST Team at SUSE LINUX GmbH IRC: dgdavid
-- -- David Díaz YaST Team at SUSE LINUX GmbH IRC: dgdavid
El vie, 05-11-2021 a las 11:13 +0000, David Díaz escribió:
On Fri, 2021-11-05 at 10:30 +0000, David Díaz wrote:
On Thu, 2021-11-04 at 16:10 +0000, José Iván López González wrote:
On 11/4/21 13:24, Imobach Gonzalez Sosa wrote:
Thinking a little bit further, would it make sense to unify the packages installation progress and the finish clients screen into a single one? After all, we could display a message below the progress bar ("installing packages", "installing the bootloader", etc.).
What do you think?
I like the idea.
I like it too. As a user, those details have been never useful to me.
Perhaps we can offer a "Show details" option for those who are interested to see in detail what's going on. I think Ubuntu and others already do it with a collapsible widget. Deepin[1][2] does it by interchanging the slider with the expert output (aka log).
Althought I like more how it is presented in elementary OS [1][2]
[1] https://paste.opensuse.org/2dfde486 [2] https://paste.opensuse.org/ea0a54b9
In our case, I would say that our logs are not ready to be shown to the end user. They contain a lot of unneeded stuff, there are typos, and so on. It is maybe time to think about cleaning up our logs? 🙂 Regards, Imo -- Imobach González Sosa YaST Team at SUSE LLC https://imobachgs.github.io/
On 11/5/21 11:37, Imobach Gonzalez Sosa wrote:
El vie, 05-11-2021 a las 11:13 +0000, David Díaz escribió:
Althought I like more how it is presented in elementary OS [1][2]
[1] https://paste.opensuse.org/2dfde486 [2] https://paste.opensuse.org/ea0a54b9
In our case, I would say that our logs are not ready to be shown to the end user. They contain a lot of unneeded stuff, there are typos, and so on. It is maybe time to think about cleaning up our logs? 🙂
Instead of logs, maybe we can show the list of actions we have now: - creating partitions - downloading yast2-sound - installing yast2-sound ... - installing bootloader ... -- José Iván López González YaST Team at SUSE LINUX GmbH IRC: jilopez
On Fri, 5 Nov 2021 11:41:27 +0000 José Iván López González <jlopez@suse.de> wrote:
On 11/5/21 11:37, Imobach Gonzalez Sosa wrote:
El vie, 05-11-2021 a las 11:13 +0000, David Díaz escribió:
Althought I like more how it is presented in elementary OS [1][2]
[1] https://paste.opensuse.org/2dfde486 [2] https://paste.opensuse.org/ea0a54b9
In our case, I would say that our logs are not ready to be shown to the end user. They contain a lot of unneeded stuff, there are typos, and so on. It is maybe time to think about cleaning up our logs? 🙂
Instead of logs, maybe we can show the list of actions we have now:
- creating partitions - downloading yast2-sound - installing yast2-sound
As said, it is against our goal to provide better experience with parallel download/install. It is hard to write something to user if there are multiple things doing currently. So it can be at max someething like "start download of yast2-sound", "finish download of yast2-sound", ... Josef
... - installing bootloader ...
El vie, 05-11-2021 a las 13:31 +0100, josef Reidinger escribió:
On Fri, 5 Nov 2021 11:41:27 +0000 José Iván López González <jlopez@suse.de> wrote:
On 11/5/21 11:37, Imobach Gonzalez Sosa wrote:
El vie, 05-11-2021 a las 11:13 +0000, David Díaz escribió:
Althought I like more how it is presented in elementary OS [1][2]
[1] https://paste.opensuse.org/2dfde486 [2] https://paste.opensuse.org/ea0a54b9
In our case, I would say that our logs are not ready to be shown to the end user. They contain a lot of unneeded stuff, there are typos, and so on. It is maybe time to think about cleaning up our logs? 🙂
Instead of logs, maybe we can show the list of actions we have now:
- creating partitions - downloading yast2-sound - installing yast2-sound
As said, it is against our goal to provide better experience with parallel download/install. It is hard to write something to user if there are multiple things doing currently. So it can be at max someething like "start download of yast2-sound", "finish download of yast2-sound", ... Josef
In my opinion, that's too much. For now, I would not show the logs, but just the main steps, and that's it. In general, I would stick to Josef's original proposal and I would consider merging the "finish clients" screen too. But step by step 🙂 Regards, Imo -- Imobach González Sosa YaST Team at SUSE LLC https://imobachgs.github.io/
On 11/5/21 13:34, Imobach Gonzalez Sosa wrote:
El vie, 05-11-2021 a las 13:31 +0100, josef Reidinger escribió:
On Fri, 5 Nov 2021 11:41:27 +0000 José Iván López González <jlopez@suse.de> wrote:
On 11/5/21 11:37, Imobach Gonzalez Sosa wrote:
El vie, 05-11-2021 a las 11:13 +0000, David Díaz escribió:
Althought I like more how it is presented in elementary OS [1][2]
[1] https://paste.opensuse.org/2dfde486 [2] https://paste.opensuse.org/ea0a54b9
In our case, I would say that our logs are not ready to be shown to the end user. They contain a lot of unneeded stuff, there are typos, and so on. It is maybe time to think about cleaning up our logs? 🙂
Instead of logs, maybe we can show the list of actions we have now:
- creating partitions - downloading yast2-sound - installing yast2-sound
As said, it is against our goal to provide better experience with parallel download/install. It is hard to write something to user if there are multiple things doing currently. So it can be at max someething like "start download of yast2-sound", "finish download of yast2-sound", ... Josef
In my opinion, that's too much. For now, I would not show the logs, but just the main steps, and that's it.
In general, I would stick to Josef's original proposal and I would consider merging the "finish clients" screen too. But step by step 🙂
Agreed. Just showing some general information about what's going on (like the number of pending packages), together with the release notes is the perfect solution in my opinion. We always complain users don't read the release notes, so let's put them before their eyes with no other option. I don't like the ideas of "show details" or "display logs". I don't think there is any real value in having logs scrolling through the screen. It's just placebo for those who want to feel they are in control of the internal details. ;-) Don't get me wrong, I'm one of those addicts to scrolling geeky messages and I hated when Linux distributions adopted splash screens during booting. But being realistic there is probably not a real use case for them in the installation process. Even if the process freezes (something that I have never seen personally or in a report), I don't think having those visible logs would make any difference in that case. Running logs are just pr0n for geeks. :-) Cheers. -- Ancor González Sosa YaST Team at SUSE Software Solutions
Hello Everyone, On Fri, 2021-11-05 at 14:41 +0100, Ancor Gonzalez Sosa wrote:
Agreed. Just showing some general information about what's going on (like the number of pending packages), together with the release notes is the perfect solution in my opinion. We always complain users don't read the release notes, so let's put them before their eyes with no other option.
A user's perspective: the progress bars that the installer is showing currently for the number of pending packages and the ETA is really useful. May I request the older "slideshow" be brought back? I'm speaking as both a user and an engineer - in our product, we were using the Slide Shows to illustrate some of the features of the product. But in SLES 15 and Leap 15.x, the yast2- slideshow package has been moved out. The slide shows were helpful both from a promotional as well as educational point of view. As a user, I would be more interested in the "Features" rather than the "Release Notes". Sure, Release Notes are useful and is already available, but most of the times, I miss reading the wiki page for the Features. For example, until last week, I didn't know about Tilix in Leap 15.2 even though I've been running 15.2 for more than a year now. And while reading about Tilix, I came to know about OnionShare. (Sure, you can call me someone living under a rock! :-) Regards, Srinidhi.
On Fri, 2021-11-05 at 14:41 +0100, Ancor Gonzalez Sosa wrote:
[...]
In general, I would stick to Josef's original proposal and I would consider merging the "finish clients" screen too. But step by step 🙂
Agreed.
I fully agree too :) As said, I was just bringing another option over the table... but clearly the Josef proposal is the best one in the path to achieving a simple, yet enough, installation screen. Nevertheless, you have opening/resuming an interesting topic here: our logs need LOVE too. But let discuss it in another thread... when the time permits it. Regards! [...] -- David Díaz YaST Team at SUSE LINUX GmbH IRC: dgdavid
On 2021-11-05 12:37, Imobach Gonzalez Sosa wrote:
In our case, I would say that our logs are not ready to be shown to the end user.
No, they definitely are not. They are much too detailed. They were never meant for end users. Logging is done on many levels, and the log level is even configurable. An end user needs messages that are specifically designed for an end user; i.e. - communicating in terms that an end user can understand - translated (!) messages [*] - the right amount of information, i.e. one line per message - don't swamp the user with irrelevant details [*] If anybody considers that or even thinks loudly about it, I will refuse handling any bugs in the future. ;-) Just think about an y2log full of messages in Finnish or Hungarian language; you don't even need to go as far as Chinese or Korean. That would completely defeat the purpose of the y2log as a debugging tool for us.
They contain a lot of unneeded stuff, there are typos, and so on. It is maybe time to think about cleaning up our logs? 🙂
It's ALWAYS time for cleaning up the logs. I have been asking for that for many years. But this is not the reason for that: We have different needs from logs than an end user. We need more details (and I'd very much prefer proper formatting, not just dumping 10k of garbage in one single line) and better classification, e.g. not allowing external tools like Dracut to dump every message on stderr because of insane limitations of other tools that grab those messages. But that's another story for another day. Kind regards -- Stefan Hundhammer <shundhammer@suse.de> YaST Developer SUSE Software Solutions Germany GmbH GF: Ivo Totev; HRB 36809, AG Nürnberg
On Mon, 08 Nov 2021 11:47:27 +0100 shundhammer <shundhammer@suse.de> wrote:
But this is not the reason for that: We have different needs from logs than an end user. We need more details (and I'd very much prefer proper formatting, not just dumping 10k of garbage in one single line)
This is good idea and whats more now it is even good time for it. Previously we had to do it manually for each log line as old testsuite compare logs (so all y2* calls to log use ycp data format), but now with old test suite dead/removed we can improve data formatting. It used sformat on each data passed [1] as extra arguments to old data calls. So what we can do is to add to more modern logger method like data_dump and for old y2* logs calls use something similar. Maybe something like `pp` can help there. Josef [1] https://github.com/yast/yast-ruby-bindings/blob/master/src/ruby/yast/logger....
On 2021-11-04 14:24, Imobach Gonzalez Sosa wrote:
To be honest, usually that information goes too fast, so it is nearly impossible for me to find something useful there. And, if something goes wrong, I would expect YaST to notify me about the problem.
As long as it scrolls by very fast, you don't need to bother about it. But some packages take forever, and that's when I get interested in what is happening: - Did I really want to install LaTeX that is now generating a ton of fonts? Or do I want to be careful next time to avoid anything that will drag that package in; and consume a ton of disk space, too? - Something that downloads files from an external site in its post-install script might be stuck. Maybe I can do something about that; or simply the knowledge that this is what keeps me waiting may be important. etc. etc.; we always made the claim that we put the user in charge, so we should clearly give him the information he needs to make decisions, or to do things immediately. With this approach, we are dumbing him down to a pure consumer who doesn't get to decide anything; he has to accept whatever we do to that machine. This is not the Linux way. This was never the YaST way. Why are we choosing this route? Empower the user, don't treat him as somebody powerless.
It contains release notes that contain useful information
For some, maybe. Certainly not for everybody.
I usually find release notes quite useful. If release notes are informative and well-written, and think it might be a good idea.
It might be a good OPTION to read them at this point. But if I am interested in them, I want to take my time, and I want to be able to keep an editor window open in parallel to take notes; or a terminal window to experiment with things, to have a look at the mentioned config files, to read the latest man page of that command. Package installation is not the right time for that; at least for me it isn't.
and also has just one progress bar. For that bar remove keep always just remaining size and count of packages, so user has idea how it does,
That is much too coarse IMHO.
+1 to Josef proposal. We could add "remaining time" information
The remaining time was always a lie. I told you the story of that "pessimistic factor" several times already; that non-feature was demanded by the product manager back then. It was never a reasonable estimation; that fact is hidden only by constantly recalculating the expected remaining time, and constantly reducing the "pessimistic factor" from initially 2.0 to 1.0 when we get near the end. Anybody watching closely will observe that the times are jumping wildly, especially when packages are involved that perform lengthy actions in their post-install script. Those times are wrong. They always were. They always will be. It may average out in the end because it's a lot of packages, so inaccuracies may not become too obvious in most cases. But we are basically making up the numbers that we display to the user.
Yes, please, let's get rid of it.
One thing that we agree upon. That's good. ;-)
Thinking a little bit further, would it make sense to unify the packages installation progress and the finish clients screen into a single one?
No. That would be a bad UI experience; right now you can look from far away to get an impression how far the installation progressed. With a unified dialog, you'd have to carefully read the text. That would be a change for the worse. Kind regards -- Stefan Hundhammer <shundhammer@suse.de> YaST Developer SUSE Software Solutions Germany GmbH GF: Ivo Totev; HRB 36809, AG Nürnberg
El lun, 08-11-2021 a las 11:04 +0100, shundhammer escribió:
Hi all,
As long as it scrolls by very fast, you don't need to bother about it.
But some packages take forever, and that's when I get interested in what is happening:
- Did I really want to install LaTeX that is now generating a ton of fonts? Or do I want to be careful next time to avoid anything that will drag that package in; and consume a ton of disk space, too?
Actually, I am not sure whether the installation progress is the right place to find out that LaTeX is taking a ton of disk space.
- Something that downloads files from an external site in its post-install script might be stuck. Maybe I can do something about that; or simply the knowledge that this is what keeps me waiting may be important.
I do not think there is anything you can do to speed up things at that point. IMHO, that information is not relevant at all.
etc. etc.; we always made the claim that we put the user in charge, so we should clearly give him the information he needs to make decisions, or to do things immediately.
With this approach, we are dumbing him down to a pure consumer who doesn't get to decide anything; he has to accept whatever we do to that machine. This is not the Linux way. This was never the YaST way. Why are we choosing this route?
Empower the user, don't treat him as somebody powerless.
Sorry, but I do not think we are treating the user in that way by simplyfing the feedback screen. [..]
It might be a good OPTION to read them at this point. But if I am interested in them, I want to take my time, and I want to be able to keep an editor window open in parallel to take notes; or a terminal window to experiment with things, to have a look at the mentioned config files, to read the latest man page of that command. Package installation is not the right time for that; at least for me it isn't.
IMHO, displaying information about the product you are installing is rather useful. I usually read release notes, even when I am going to upgrade my desktop system. But, sure, it is an option. You can just ignore them and read them later (or before). But showing the release notes will not harm any user. However, if we can use the same screen space to do something better... [..]
The remaining time was always a lie. I told you the story of that "pessimistic factor" several times already; that non-feature was demanded by the product manager back then. It was never a reasonable estimation; that fact is hidden only by constantly recalculating the expected remaining time, and constantly reducing the "pessimistic factor" from initially 2.0 to 1.0 when we get near the end. Anybody watching closely will observe that the times are jumping wildly, especially when packages are involved that perform lengthy actions in their post-install script.
Those times are wrong. They always were. They always will be. It may average out in the end because it's a lot of packages, so inaccuracies may not become too obvious in most cases. But we are basically making up the numbers that we display to the user.
OK, not a problem, let's keep them out.
Yes, please, let's get rid of it.
One thing that we agree upon. That's good. ;-)
Thinking a little bit further, would it make sense to unify the packages installation progress and the finish clients screen into a single one?
No. That would be a bad UI experience; right now you can look from far away to get an impression how far the installation progressed. With a unified dialog, you'd have to carefully read the text. That would be a change for the worse.
Sorry, but I do not think so. Now we have two different UIs: one about software installation (the slideshow itself) and the other about the rest of things that happen *after* installing the software. IMHO, if we simplify the slideshow, that difference becomes somehow artificial. You are installing the system and installing the software is just another step. If we define a clear UI to track the installation progress, you do not need to separate both phases. Having said that, we are not aiming to unify both screens now. We are mainly focused into simplifying the slideshow.
Kind regards
Regards, Imo -- Imobach González Sosa YaST Team at SUSE LLC https://imobachgs.github.io/
On 11/4/21 2:24 PM, Imobach Gonzalez Sosa wrote:
To be honest, usually that information goes too fast, so it is nearly impossible for me to find something useful there.
And now imagine the download and installation will happen in parallel...
I usually find release notes quite useful. If release notes are informative and well-written, and think it might be a good idea.
The release notes are usually too technical, so they might not be interesting all users. On the other hand I personally looked at them several times already, which I cannot tell about the slideshow in the past... There is one advantage: the release notes are really updated for each SP (or Leap) release, compare it with the slideshow note below.
+1 to Josef proposal. We could add "remaining time" information but only if it is kind of accurate. If it is going from 5 minutes, to half and hour to 1 minute again, then it is better not to show anything.
I'd avoid any time estimations. They are really inaccurate, we got lots of bug reports about that. It can never be perfect, there are so many variables so there always be some cases when it estimates completely wrong numbers. E.g. fast SSD vs. rotational disk, local repository vs. internet repository, slow network vs. fast network, a small RPM but with long %post script... Also the problem is that the estimation is very inaccurate at the beginning and changing a lot (because of too little data). It gets better over the time, but these days the installations are pretty quick, at the time when the estimation settles down and proposes some realistic value the installation is almost over...
IMHO this is the best opportunity to get rid of that slideshow for good. It has been in zombie state for many years, yet it was always in the way.
Yes, please, let's get rid of it.
IMHO a slideshow would be nice to have. But it must contain some interesting features, nice screenshots, etc... It must be really interesting for readers. And most importantly it must be regularly updated and maintained, showing still the same texts and outdated screenshots is worse than no slideshow at all. And because I expect nobody will maintain the slideshow for us then rather do not support it at all...
Thinking a little bit further, would it make sense to unify the packages installation progress and the finish clients screen into a single one? After all, we could display a message below the progress bar ("installing packages", "installing the bootloader", etc.).
What do you think?
I do not know if that would be possible to merge all these steps, esp. how to compute the overall progress. Package installation 90% and the finish clients 10%? That would have the same problem as the time estimation mentioned above. I'd rather take smaller steps, let's improve the package installation first and then maybe (maybe!) think about that unification. -- Ladislav Slezák YaST Developer SUSE LINUX, s.r.o. Corso IIa Křižíkova 148/34 18600 Praha 8
On 11.11.21, 16:55, "Ladislav Slezak" <lslezak@suse.com<mailto:lslezak@suse.com>> wrote: On 11/4/21 2:24 PM, Imobach Gonzalez Sosa wrote: To be honest, usually that information goes too fast, so it is nearly impossible for me to find something useful there. And now imagine the download and installation will happen in parallel... My original thought was instead of a time estimation just to show a number of tasks and the current task number but I assume that parallelization could make this nearly useless as so many tasks would finish at nearly the same time after a long wait. Do we have any experience with “how parallel” the whole process will be? I usually find release notes quite useful. If release notes are informative and well-written, and think it might be a good idea. The release notes are usually too technical, so they might not be interesting all users. On the other hand I personally looked at them several times already, which I cannot tell about the slideshow in the past... There is one advantage: the release notes are really updated for each SP (or Leap) release, compare it with the slideshow note below. +1 to Josef proposal. We could add "remaining time" information but only if it is kind of accurate. If it is going from 5 minutes, to half and hour to 1 minute again, then it is better not to show anything. I'd avoid any time estimations. They are really inaccurate, we got lots of bug reports about that. It can never be perfect, there are so many variables so there always be some cases when it estimates completely wrong numbers. E.g. fast SSD vs. rotational disk, local repository vs. internet repository, slow network vs. fast network, a small RPM but with long %post script... Also the problem is that the estimation is very inaccurate at the beginning and changing a lot (because of too little data). It gets better over the time, but these days the installations are pretty quick, at the time when the estimation settles down and proposes some realistic value the installation is almost over... IMHO this is the best opportunity to get rid of that slideshow for good. It has been in zombie state for many years, yet it was always in the way. Yes, please, let's get rid of it. IMHO a slideshow would be nice to have. But it must contain some interesting features, nice screenshots, etc... It must be really interesting for readers. And most importantly it must be regularly updated and maintained, showing still the same texts and outdated screenshots is worse than no slideshow at all. And because I expect nobody will maintain the slideshow for us then rather do not support it at all... I agree. It would need to be 1. done properly 2. specific to each product variant(?) 3. updated regularly. #1 is do-able but 2&3 are hard to promise as they require regular effort from other functions. Thinking a little bit further, would it make sense to unify the packages installation progress and the finish clients screen into a single one? After all, we could display a message below the progress bar ("installing packages", "installing the bootloader", etc.). What do you think? I do not know if that would be possible to merge all these steps, esp. how to compute the overall progress. Package installation 90% and the finish clients 10%? That would have the same problem as the time estimation mentioned above. I'd rather take smaller steps, let's improve the package installation first and then maybe (maybe!) think about that unification. Have we considered some kind of small signal that the system is still running similar to a spinner/throbber? (Something similar to the small light going on and off during write operations to a hard-drive). Naturally, it would not just be an animation…that would be pointless – lol, unless it is believable enough to feel “real” 😊 I completely agree with keeping it simple until we know more or have a solid solution. -- Ken
On Thu, 04 Nov 2021 13:58:44 +0100 shundhammer <shundhammer@suse.de> wrote:
On 2021-11-04 11:14, josef Reidinger wrote:
Challenge: ----------
Libzypp supports parallel download and install. Yast installation progress does not fit it at all [1]. Issues are secondary progress bar that does not work with parallel installation. Also there are overwhelming amount of information on screen that is quite distracting. That information is often wrong like time estimation. And also table for media is a bit useless nowadays as everything is on one iso/medium, so there is no need to see when cd switch will be needed. The details tab are the most visible as it is default one.
Proposal: ---------
Remove completely that details tab and keep just release notes one[2].
Hi, at first let me thank you for providing feedback.
Yikes. That will make tracking down problems completely impossible; for us as well as for users. This is not a good idea IMHO. As a user, I want to get a general idea what's going on. More often than not, it's some specific packages that take forever to install; some post-install script building a kernel module, for example.
Not having any information about that is a huge step backwards IMHO.
Well, we still have that information, just in logs. As mentioned goal is allow parallel download and install. With current machine power I think it will be really hard to provide such kind of info. And also target user group is very is very small who needs such detailed info or even intersted what takes time during installation. I think majority of users are binary or ternary ( install, not install and option install but takes too much time ). If we really want to trace down issue with package installation and long times, then I suggest systemd approach. Simple having output like systemd-analyze that gives you all needed info for very expert usage.
It contains release notes that contain useful information
For some, maybe. Certainly not for everybody.
Well, there are basically three possible infos I see during research how other OSes do progress installation: 1. what installer currently doing ( to be honest I think majority do not care, windows express it best, it just say I am installing without any details ) 2. what issues/features you can expect after installation ( that is what release notes contain - important changes, incompatibilities, and so on ) 3. what OS provides to user ( that is what was slide show and what currently has ubuntu installater ).
and also has just one progress bar. For that bar remove keep always just remaining size and count of packages, so user has idea how it does,
That is much too coarse IMHO.
Well, it really depends on audience. I did research of other OSes and it really varies like windows desktop - just say "Preparing system and it can take several minutes". That is e.g. for me quite uncomfortable, but as seen it works for majority of world. windows server - 5 steps and having percent in each step fedora - writes installaling software and percentage ubuntu - writes retrieving or installation software and X / Y and what we writes now in details window? see link[1] in original mail Installing very_long_rpm_name_including_arch_and_version ( installed size X.Y MiB ) Installing packages ... (Remaining X.Y Gib/ X:Y:Z, ABC packages ) and it is usually redrawing so quick that it is hard to even read it. So only time when you have chance to read it is when something big comes....and to be honest that time is always completely off. In the case when I took screenshot it take 4 minutes to install and it says after 14% that it should be 71 minutes.
but do not print what exactly is installing or any time estimation. If there are more release notes allow to switch between them.
Also keep possibility to have slide show which we had in past for installation if someone create some
That slideshow seemed like a good idea back in the early 2000s. We had intended it to show highlights of the distribution that you are currently installing, to entertain the users (who were installing from CDs or DVDs back then which took a looong time) and to give them a good feeling about their new system that they were currently installing.
As mentioned above Ubuntu still uses it and when I install it I really like it. For me when I compare various progress during installation the best one, because it is positive, it shows what you can do with your system and just looks good and move the product on higher level.
It took about 7 nanoseconds until that was hijacked by marketing who misused it to show the user the OTHER products, more or less implying "duh, you got the wrong one". The idea and spirit behind the slideshow were dead at that moment, yet we were saddled with that over-complicated code.
well, even with fire you can burn whole vilage and still noone says stop using it. It is just about usage.
We had to make it over-complicated because of limitations that we had back then with YCP and the overall YaST engine; but even today it wouldn't become significantly easier, clearer or better to maintain.
Hmm, I touch it few years ago and it was not rocket science. Just show something in defined time sequence. I remember I kill all that overengineering to try to be super smart to show everything exactly once and to compute exact seconds for each frame and simple replace it with hard coded time for each frame and result works well and is quite simple.
IMHO this is the best opportunity to get rid of that slideshow for good. It has been in zombie state for many years, yet it was always in the way.
As said above for me the ubuntu solution looks from user POV still as the best one I see ( including our own ).
I propose we could do something similar to what we (Knut and I) did recently for formatting DASDs:
- One progress bar because that's really the best thing we can do
- Provide a list or several lists of packages - currently being installed - finished installing - waiting to be installed
along with the number in each category, of course.
Well, I expect for DASD formatting take serious time, but for package installation when majority of rpms is libs with KiB size, it will quickly become disco dream. Also if I look at it from user POV what I will see? currently installing X package and I have no clue what each package is...hey, there is libreoffice, I heard about it. finished installation - another bunch of packages I have no clue ( On that screenshot I provide with default SLES installation was 2k packages, do we really expect that user scan it? ) waiting to be installed - another bunch of packages I do not know...what I can do with that info?
The DASDformat prototype:
https://github.com/shundhammer/dasdfmt-proto/issues/2
the package installation would look differently, of course; but you can get some inspirations from here.
I'll happily help with more detailed UI design, but please let's not dumb this down to the point of becoming useless; and by all means let's get rid of that slideshow code monster. Nobody asked for it for at least the past 6 years (probably even for the last 10-12 years); let's bury that thing for good.
Well, for UI design and UX I add to CC Jesus, which I expect can provide more expert view and bring some fresh ideas outside of our bubble that is fascinated by watching installation progress.
Kind regards
On 04.11.21, 11:14, "josef Reidinger" <jreidinger@suse.cz<mailto:jreidinger@suse.cz>> wrote: Challenge: ---------- Libzypp supports parallel download and install. Yast installation progress does not fit it at all [1]. Issues are secondary progress bar that does not work with parallel installation. Also there are overwhelming amount of information on screen that is quite distracting. That information is often wrong like time estimation. And also table for media is a bit useless nowadays as everything is on one iso/medium, so there is no need to see when cd switch will be needed. The details tab are the most visible as it is default one. Proposal: --------- Remove completely that details tab and keep just release notes one[2]. It contains release notes that contain useful information and also has just one progress bar. For that bar remove keep always just remaining size and count of packages, so user has idea how it does, but do not print what exactly is installing or any time estimation. If there are more release notes allow to switch between them. Also keep possibility to have slide show which we had in past for installation if someone create some ( when checked other OSes, the Ubuntu slide show during installation looks probably the best from user POV ). The same changes will apply to ncurses front end[3], we just need to check why formatting of release notes are so badly formatted. And same for opensuse[4] of course. I agree completely with your suggestion to remove the progress information. I think you’ll find more internal use-cases for this than external – the commonly stated “I want to know where something fails” is, in my opinion, a bit over-rated as customers will want to look at logs to understand what went wrong. Do we receive bug reports with “I saw this text on the screen” and accept that as enough information? -- Ken
On 11/4/21 2:11 PM, Kenneth Wimer wrote:
Do we receive bug reports with “I saw this text on the screen” and accept that as enough information?
No, we would ask for the log anyway. And most likely we would pass it to the libzypp experts to check it. That's why I think we should display minimal amount of data (just the most important data like the overall progress). With parallel download and installation it would be very difficult for the user to really understand what is actually happening. And most users are not really interested in such details anyway. Ladislav
Hi, finally after a bit fighting with my video recording and video editing skills I create this result https://youtu.be/lB6S4ZCm5pk It demonstrate how progress looks when there is no slide show and no details. I include everything from initial partitioning, rpm installation, till the final configuration. The video is real-time, so feel free to skip it or change it. I just want to show it with original speed to get impression how it looks real life. The borders of video are ugly due to my skill with recordmydesktop that record window with background IRC client and my poor skill with pitivi, where I failed to cut it off. I welcome any feedback for video content. My video skill does not deserve any comment :) Thanks Josef
On Mon, Nov 15, 2021 at 10:45 AM josef Reidinger <jreidinger@suse.cz> wrote:
Hi, finally after a bit fighting with my video recording and video editing skills I create this result https://youtu.be/lB6S4ZCm5pk It demonstrate how progress looks when there is no slide show and no details. I include everything from initial partitioning, rpm installation, till the final configuration. The video is real-time, so feel free to skip it or change it. I just want to show it with original speed to get impression how it looks real life. The borders of video are ugly due to my skill with recordmydesktop that record window with background IRC client and my poor skill with pitivi, where I failed to cut it off. I welcome any feedback for video content. My video skill does not deserve any comment :)
Could we have the package name show up in the text as it installs packages? That is, text like: "Installing package <packagename> (1/2345)..."? -- 真実はいつも一つ！/ Always, there's only one truth!
On 11/15/21 16:56, Neal Gompa wrote:
On Mon, Nov 15, 2021 at 10:45 AM josef Reidinger <jreidinger@suse.cz> wrote:
Hi, finally after a bit fighting with my video recording and video editing skills I create this result https://youtu.be/lB6S4ZCm5pk It demonstrate how progress looks when there is no slide show and no details. I include everything from initial partitioning, rpm installation, till the final configuration. The video is real-time, so feel free to skip it or change it. I just want to show it with original speed to get impression how it looks real life. The borders of video are ugly due to my skill with recordmydesktop that record window with background IRC client and my poor skill with pitivi, where I failed to cut it off. I welcome any feedback for video content. My video skill does not deserve any comment :)
Could we have the package name show up in the text as it installs packages? That is, text like: "Installing package <packagename> (1/2345)..."?
The whole thread started because of the introduction of parallel downloading and installation of packages in libzypp, which made obsolete the old approach of showing the package been processed. Cheers. -- Ancor González Sosa YaST Team at SUSE Software Solutions
On Mon, Nov 15, 2021 at 11:00 AM Ancor Gonzalez Sosa <ancor@suse.de> wrote:
On 11/15/21 16:56, Neal Gompa wrote:
On Mon, Nov 15, 2021 at 10:45 AM josef Reidinger <jreidinger@suse.cz> wrote:
Hi, finally after a bit fighting with my video recording and video editing skills I create this result https://youtu.be/lB6S4ZCm5pk It demonstrate how progress looks when there is no slide show and no details. I include everything from initial partitioning, rpm installation, till the final configuration. The video is real-time, so feel free to skip it or change it. I just want to show it with original speed to get impression how it looks real life. The borders of video are ugly due to my skill with recordmydesktop that record window with background IRC client and my poor skill with pitivi, where I failed to cut it off. I welcome any feedback for video content. My video skill does not deserve any comment :)
Could we have the package name show up in the text as it installs packages? That is, text like: "Installing package <packagename> (1/2345)..."?
The whole thread started because of the introduction of parallel downloading and installation of packages in libzypp, which made obsolete the old approach of showing the package been processed.
We don't parallel install packages, only downloading, and in the new mode, they're broken up into distinct phases. You know how many to download and you can do that up front, then you're still serially installing packages. -- 真実はいつも一つ！/ Always, there's only one truth!
On Mon, 15 Nov 2021 11:06:28 -0500 Neal Gompa <ngompa13@gmail.com> wrote:
On Mon, Nov 15, 2021 at 11:00 AM Ancor Gonzalez Sosa <ancor@suse.de> wrote:
On 11/15/21 16:56, Neal Gompa wrote:
On Mon, Nov 15, 2021 at 10:45 AM josef Reidinger <jreidinger@suse.cz> wrote:
Hi, finally after a bit fighting with my video recording and video editing skills I create this result https://youtu.be/lB6S4ZCm5pk It demonstrate how progress looks when there is no slide show and no details. I include everything from initial partitioning, rpm installation, till the final configuration. The video is real-time, so feel free to skip it or change it. I just want to show it with original speed to get impression how it looks real life. The borders of video are ugly due to my skill with recordmydesktop that record window with background IRC client and my poor skill with pitivi, where I failed to cut it off. I welcome any feedback for video content. My video skill does not deserve any comment :)
Could we have the package name show up in the text as it installs packages? That is, text like: "Installing package <packagename> (1/2345)..."?
The whole thread started because of the introduction of parallel downloading and installation of packages in libzypp, which made obsolete the old approach of showing the package been processed.
We don't parallel install packages, only downloading, and in the new mode, they're broken up into distinct phases. You know how many to download and you can do that up front, then you're still serially installing packages.
Still question is how to display it...it can end with something like downloading packages... Installing package A (1/300) downloading packages Installing package B (2/300) Installing package C (3/300) downloading packages which I found quite confusing. Another option is to show package A installed and download on background. And also approach without package names allows us to not change if in future it will be decided to also parallel install ( like e.g. unpack rpm, do some check like file conflicts and other parts that can be done in parallel and maybe call just scripts in serial?). Thanks for feedback Josef
On Mon, Nov 15, 2021 at 11:49 AM josef Reidinger <jreidinger@suse.cz> wrote:
On Mon, 15 Nov 2021 11:06:28 -0500 Neal Gompa <ngompa13@gmail.com> wrote:
On Mon, Nov 15, 2021 at 11:00 AM Ancor Gonzalez Sosa <ancor@suse.de> wrote:
On 11/15/21 16:56, Neal Gompa wrote:
On Mon, Nov 15, 2021 at 10:45 AM josef Reidinger <jreidinger@suse.cz> wrote:
Hi, finally after a bit fighting with my video recording and video editing skills I create this result https://youtu.be/lB6S4ZCm5pk It demonstrate how progress looks when there is no slide show and no details. I include everything from initial partitioning, rpm installation, till the final configuration. The video is real-time, so feel free to skip it or change it. I just want to show it with original speed to get impression how it looks real life. The borders of video are ugly due to my skill with recordmydesktop that record window with background IRC client and my poor skill with pitivi, where I failed to cut it off. I welcome any feedback for video content. My video skill does not deserve any comment :)
Could we have the package name show up in the text as it installs packages? That is, text like: "Installing package <packagename> (1/2345)..."?
The whole thread started because of the introduction of parallel downloading and installation of packages in libzypp, which made obsolete the old approach of showing the package been processed.
We don't parallel install packages, only downloading, and in the new mode, they're broken up into distinct phases. You know how many to download and you can do that up front, then you're still serially installing packages.
Still question is how to display it...it can end with something like
downloading packages... Installing package A (1/300) downloading packages Installing package B (2/300) Installing package C (3/300) downloading packages
which I found quite confusing. Another option is to show package A installed and download on background. And also approach without package names allows us to not change if in future it will be decided to also parallel install ( like e.g. unpack rpm, do some check like file conflicts and other parts that can be done in parallel and maybe call just scripts in serial?).
I'm saying *don't intermix downloading and installing*, and the new mode in libzypp does not allow that. It's just downloading -> installing -> done. -- 真実はいつも一つ！/ Always, there's only one truth!
On Mon, 15 Nov 2021 11:53:42 -0500 Neal Gompa <ngompa13@gmail.com> wrote:
On Mon, Nov 15, 2021 at 11:49 AM josef Reidinger <jreidinger@suse.cz> wrote:
On Mon, 15 Nov 2021 11:06:28 -0500 Neal Gompa <ngompa13@gmail.com> wrote:
On Mon, Nov 15, 2021 at 11:00 AM Ancor Gonzalez Sosa <ancor@suse.de> wrote:
On 11/15/21 16:56, Neal Gompa wrote:
On Mon, Nov 15, 2021 at 10:45 AM josef Reidinger <jreidinger@suse.cz> wrote:
Hi, finally after a bit fighting with my video recording and video editing skills I create this result https://youtu.be/lB6S4ZCm5pk It demonstrate how progress looks when there is no slide show and no details. I include everything from initial partitioning, rpm installation, till the final configuration. The video is real-time, so feel free to skip it or change it. I just want to show it with original speed to get impression how it looks real life. The borders of video are ugly due to my skill with recordmydesktop that record window with background IRC client and my poor skill with pitivi, where I failed to cut it off. I welcome any feedback for video content. My video skill does not deserve any comment :)
Could we have the package name show up in the text as it installs packages? That is, text like: "Installing package <packagename> (1/2345)..."?
The whole thread started because of the introduction of parallel downloading and installation of packages in libzypp, which made obsolete the old approach of showing the package been processed.
We don't parallel install packages, only downloading, and in the new mode, they're broken up into distinct phases. You know how many to download and you can do that up front, then you're still serially installing packages.
Still question is how to display it...it can end with something like
downloading packages... Installing package A (1/300) downloading packages Installing package B (2/300) Installing package C (3/300) downloading packages
which I found quite confusing. Another option is to show package A installed and download on background. And also approach without package names allows us to not change if in future it will be decided to also parallel install ( like e.g. unpack rpm, do some check like file conflicts and other parts that can be done in parallel and maybe call just scripts in serial?).
I'm saying *don't intermix downloading and installing*, and the new mode in libzypp does not allow that. It's just downloading -> installing -> done.
I am not sure if I get it. So it will look like on ubuntu? Downloading some set and then install it, then again download another set and install it? I thought it will download everything in parallel from more sources and install what is ready and dependencies allows it. Also one more question. What is benefit of knowing what package is currently installing? My rough estimation is that 70% of packages are unknown to user as it is some library or plugin that they probably never heard about it. And also often they are installed so quickly that you have problem to see its name. Experienced user can maybe see some known name and remember that it take more time, but I am not sure how it help him. In general I plan to give it a bit testing with new libzypp in TW and enable that new mode by environment variable to see the result. Josef
On Mon, Nov 15, 2021 at 4:06 PM josef Reidinger <jreidinger@suse.cz> wrote:
On Mon, 15 Nov 2021 11:53:42 -0500 Neal Gompa <ngompa13@gmail.com> wrote:
On Mon, Nov 15, 2021 at 11:49 AM josef Reidinger <jreidinger@suse.cz> wrote:
On Mon, 15 Nov 2021 11:06:28 -0500 Neal Gompa <ngompa13@gmail.com> wrote:
On Mon, Nov 15, 2021 at 11:00 AM Ancor Gonzalez Sosa <ancor@suse.de> wrote:
On 11/15/21 16:56, Neal Gompa wrote:
On Mon, Nov 15, 2021 at 10:45 AM josef Reidinger <jreidinger@suse.cz> wrote: > > Hi, > finally after a bit fighting with my video recording and video editing skills I create this result https://youtu.be/lB6S4ZCm5pk > It demonstrate how progress looks when there is no slide show and no details. I include everything from initial partitioning, rpm installation, till the final configuration. > The video is real-time, so feel free to skip it or change it. I just want to show it with original speed to get impression how it looks real life. > The borders of video are ugly due to my skill with recordmydesktop that record window with background IRC client and my poor skill with pitivi, where I failed to cut it off. > I welcome any feedback for video content. My video skill does not deserve any comment :) >
Could we have the package name show up in the text as it installs packages? That is, text like: "Installing package <packagename> (1/2345)..."?
The whole thread started because of the introduction of parallel downloading and installation of packages in libzypp, which made obsolete the old approach of showing the package been processed.
We don't parallel install packages, only downloading, and in the new mode, they're broken up into distinct phases. You know how many to download and you can do that up front, then you're still serially installing packages.
Still question is how to display it...it can end with something like
downloading packages... Installing package A (1/300) downloading packages Installing package B (2/300) Installing package C (3/300) downloading packages
which I found quite confusing. Another option is to show package A installed and download on background. And also approach without package names allows us to not change if in future it will be decided to also parallel install ( like e.g. unpack rpm, do some check like file conflicts and other parts that can be done in parallel and maybe call just scripts in serial?).
I'm saying *don't intermix downloading and installing*, and the new mode in libzypp does not allow that. It's just downloading -> installing -> done.
I am not sure if I get it. So it will look like on ubuntu? Downloading some set and then install it, then again download another set and install it? I thought it will download everything in parallel from more sources and install what is ready and dependencies allows it.
Also one more question. What is benefit of knowing what package is currently installing? My rough estimation is that 70% of packages are unknown to user as it is some library or plugin that they probably never heard about it. And also often they are installed so quickly that you have problem to see its name. Experienced user can maybe see some known name and remember that it take more time, but I am not sure how it help him.
In general I plan to give it a bit testing with new libzypp in TW and enable that new mode by environment variable to see the result.
There will be no more "download then install then download then install", it'll be "download everything, then install everything". Basically, it'll work like how DNF does it. -- 真実はいつも一つ！/ Always, there's only one truth!
On Mon, 15 Nov 2021 10:56:05 -0500 Neal Gompa <ngompa13@gmail.com> wrote:
On Mon, Nov 15, 2021 at 10:45 AM josef Reidinger <jreidinger@suse.cz> wrote:
Hi, finally after a bit fighting with my video recording and video editing skills I create this result https://youtu.be/lB6S4ZCm5pk It demonstrate how progress looks when there is no slide show and no details. I include everything from initial partitioning, rpm installation, till the final configuration. The video is real-time, so feel free to skip it or change it. I just want to show it with original speed to get impression how it looks real life. The borders of video are ugly due to my skill with recordmydesktop that record window with background IRC client and my poor skill with pitivi, where I failed to cut it off. I welcome any feedback for video content. My video skill does not deserve any comment :)
Could we have the package name show up in the text as it installs packages? That is, text like: "Installing package <packagename> (1/2345)..."?
Sadly as explained in original email it is not possible with planned new feature for parallel download/install of packages. As there will be multiple of them, I think it just cause confusion if there will be multiple packages and it change often. Even now for many packages it is hard to see what is installed if it is just few KiB library. Josef
Hi, Josef, yhis was really a very, very bad decision. I just installed the first SP4 system and the new progress display is a nightmare. This is not MacOS or Windows where people are intentionally kept dumb. This is Linux where we are used to see what's going on and get detailed information. When I first checked how installation is going, I saw the single progress bar stuck for almost a minute with neither the percentage nor the package count moving. So I ssh'd into the system to see why it was stuck or if it had crashed. I couldn't easily see what's going on because it was just some kworker doing sth. With the old system I had seen that package xy was installing, how big it was and where the progress bar for this single package is. It would have been clear then that this was a huge package and that it would likely take some work in %posttrans. Argueing that parallel download and/or install progress messages or several bars are would be confusing for the user is nonsense. If you were afraid of that you could just make it possible to hide/unhide the detailed information just like with the ESC key during boot to switch between slideshow or kernel messages. And displaying parallel operations is really not a problem. You can stack progress bars and restrict it to show e.g. only up to five of them to keep the screen clear. The solution you chose was the worst of all. Hiding information and keeping the user dumb and uninformed is not the way Linux works. And you are really argueing "show less to avoid confusion when more parallel approach will be implemented"? Do you think users are silly and too stupid to bear more than one progress bar? Nobody needs slideshows of release notes or other unimportant stuff. What we need is information what's going on with the installation. You really destroyed a formerly extremly useful and informative GUI and should definitely consider bringing it back (make it optional to show if you like). For now, watching the AY installation is as frustrating as watching a Windows or MacOS installation. cu, Frank -- Dipl.-Inform. Frank Steiner Web: http://www.bio.ifi.lmu.de/~steiner/ Lehrstuhl f. Bioinformatik Mail: http://www.bio.ifi.lmu.de/~steiner/m/ LMU, Amalienstr. 17 Phone: +49 89 2180-4049 80333 Muenchen, Germany Fax: +49 89 2180-99-4049 * Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. *
On Tue, Jul 5, 2022 at 9:53 AM Frank Steiner <fsteiner-mail1@bio.ifi.lmu.de> wrote:
Hi,
Josef, yhis was really a very, very bad decision. I just installed the first SP4 system and the new progress display is a nightmare.
I can confirm that from posts on openSUSE forum new progress information got rather negative acceptance.
This is not MacOS or Windows where people are intentionally kept dumb.
How are your conspiracy theories relevant to the installation progress dialog in openSUSE?
This is Linux where we are used to see what's going on and get detailed information.
You may be surprised, but most *users* do not care. Please keep technical discussion technical.
Andrei Borzenkov wrote:
You may be surprised, but most *users* do not care.
Please keep technical discussion technical.
I apologize if I sounded rude, I was just a little disappointed and angry, sorry for that! So, maybe it would be an option to re-add a more verbose output and make it optional, either by some GUI element and/or by some option in the AY xml control file. Then users have the choice, just like with the normal boot process... cu, Frank -- Dipl.-Inform. Frank Steiner Web: http://www.bio.ifi.lmu.de/~steiner/ Lehrstuhl f. Bioinformatik Mail: http://www.bio.ifi.lmu.de/~steiner/m/ LMU, Amalienstr. 17 Phone: +49 89 2180-4049 80333 Muenchen, Germany Fax: +49 89 2180-99-4049 * Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. *
Hi all, I would like to understand this better from a UX perspective. What action can a user take during installation to remedy a situation in which some package couldn’t be installed? What circumstances lead to these failures? Is this information available in a log file? What action can a user take during installation vs after? Is the “normal” linux text boot still accessible by a switch at the bootloader stage? Best regards, Kenneth From: Lukáš Krejza <gryffus@hkfree.org> Date: Tuesday, 5. July 2022 at 11:39 To: Andrei Borzenkov <arvidjaar@gmail.com> Cc: "yast-devel@lists.opensuse.org" <yast-devel@lists.opensuse.org> Subject: Re: Modified Progress Video Hey, Dne 5. 7. 2022 11:03 napsal uživatel Andrei Borzenkov <arvidjaar@gmail.com>: On Tue, Jul 5, 2022 at 9:53 AM Frank Steiner <fsteiner-mail1@bio.ifi.lmu.de> wrote:
Hi,
Josef, yhis was really a very, very bad decision. I just installed the first SP4 system and the new progress display is a nightmare.
I can confirm that from posts on openSUSE forum new progress information got rather negative acceptance. I fully agree with Frank. When installing, I need to see the RPM output in case something goes wrong and I also want to see which package(s) is/are currently installing, its/theirs size and preferably progress bar. I also need to have access to release notes during the instalation. More information is always better, especially when installing. Is there a _technical_ reason to hide this information from me or the users?
This is not MacOS or Windows where people are intentionally kept dumb.
How are your conspiracy theories relevant to the installation progress dialog in openSUSE?
This is Linux where we are used to see what's going on and get detailed information.
You may be surprised, but most *users* do not care. Please keep technical discussion technical. Regards, Gfs on the road
On 2022-07-05 08:52, Frank Steiner wrote:
Hi,
Josef, this was really a very, very bad decision. I just installed the first SP4 system and the new progress display is a nightmare.
Frank, first of all, thanks for your input. We do listen to our users; but sometimes you simply can't make every one of them happy. Sometimes there are conflicting requirements, and whichever path we choose, some users may become unhappy. Josef was just the messenger here; the decision was made with many more people, including the YaST team, the libzypp team, product and project managers. If you go back in the history of this thread, you will find that I was a very vocal advocate of much more detailed user feedback. That may have to do with me having written that old user interface back many years (15 or more) ago. Back then, there was much more detailed progress information because everything was so much slower back then, and because having to deal with a whole stack of CDs (yes, CDs, not only DVDs!) was a very common scenario; you might have to change them during installation, and in pathological cases, you might even have to insert the same one multiple times (even though we tried to minimize that, of course). Back then, reducing the progress feedback was simply not an option; because everything took so long. Not only did we try to keep the user entertained, we also needed to reassure him that things were still going on and didn't crash, or a network connection was stuck. Things have changed since then. CDs are no longer a thing, not even DVDs; you either use an ISO on a USB stick, or you install via Internet or LAN. Even with an insanely larger amount of packages that you typically install, and those packages each becoming larger all the time, a typical installation is at least ten times as quick as it used to be in the olden days. To speed things up even more, libzypp now supports parallel operations: Downloading multiple packages in parallel, and installing a bunch of downloaded packages in parallel to that, too. Of course that makes useful progress reporting much more difficult; not only technically, also from a user interface perspective. Such a user interface may become overwhelmingly complex really quickly; it is a real challenge to present that information in a way so the average user can make sense of it. We used to be on the very geeky side of that with the old UI. Personally, I liked that (which may have to do with me also having come up with that concept), but there were always those wo wanted it greatly simplified, bringing up the MacOS X installation as a shining example (don't get me started). But the truth is that the old installation progress UI was always on the verge of being too complex, and we had to add complexity all the time: E.g. tabs for the release notes and the slide show (that was misused as an advertisement platform from day one). So now there was a change; a quite radical change. The pendulum swung out to the other extreme, greatly simplifying that UI. You might not have noticed all the changes and variations that we had in the meantime; there was a reason why we asked the community for feedback as early as last November. We knew that this topic would be controversial, and our intent was to collect user feedback early on. Sadly, there was very little user feedback; at least in the time frame that would have allowed us to do any major changes. We did improvements where we saw that they would help; for example here: https://github.com/yast/yast-packager/pull/609 https://github.com/yast/yast-yast2/pull/1250 Please have a look at some of the videos in those pull requests. Those changes were the result of feedback that came from within the team, from our QA people, and from community users. What we tried here was to make it look very simple, but to give more feedback when it was needed; thus those delayed progress pop-ups when something takes longer than usual. You still get additional feedback, but not when it just flashes by in the fraction of a second; only when it takes noticeably long (more than about 3-4 seconds). That may include post-install scripts or similar operations that are usually done very quickly, but pathological cases may take minutes. The big mantra of UI design is: It's not perfect when there is nothing anymore that you could reasonably add, but when there is nothing anymore that you can reasonably take away. That is the philosophy that we were following here. Is it perfect? No; nothing ever is. Is it final? Probably not; it may need some iterations of improvements. Are there bugs? Of course. We need to fix them one by one. Is it so broken that it's unusable? IMHO no. Is it different than it used to be? Yes, it sure is. And the last point is probably what caused most of this irritation. A major change such as this certainly takes some getting used to.
This is not MacOS or Windows where people are intentionally kept dumb. This is Linux where we are used to see what's going on and get detailed information.
Yes and no. MacOS and Windows certainly take this to extremes; they inform the user about hardly anything. If anything goes wrong, you usually have no idea what to do or even how to ask on the Internet for possible solutions. On the other hand, MacOS X in particular is generally highly praised for its user interface; for its perceived simplicity. Others call it dumbed down. That's a matter of personal preferences. But in many areas, they do have a point.
When I first checked how installation is going, I saw the single progress bar stuck for almost a minute with neither the percentage nor the package count moving.
That I would consider a bug. If anything is stuck for that long, we need to do something about it. If this is a single operation that may take a long time, we may need to use one more of those "delayed progress popups". But that does not invalidate the whole concept of using a single unified progress bar.
So I ssh'd into the system to see why it was stuck or if it had crashed. I couldn't easily see what's going on because it was just some kworker doing sth.
Looking at /var/log/YaST2/y2log may give some insights what was going on at that time. That's not meant for the casual user, of course; it is for expert users or for YaST developers.
With the old system I had seen that package xy was installing, how big it was and where the progress bar for this single package is. It would have been clear then that this was a huge package and that it would likely take some work in %posttrans.
Those pre- and post-scripts should now get their own delayed progress pop-ups, so in this regard it's even better now than it used to be.
Argueing that parallel download and/or install progress messages or several bars are would be confusing for the user is nonsense.
No, it is not. We tried several things in similar areas like formatting DASDs on s/390 mainframes; and it's much more complex for the users, and the code is becoming more of a nightmare and considerably less maintainable. And that was another one of the problems we had with the old installation progress reporting: The technical debt had accumulated too much over the decades (!) that we kept adding to and changing that part. It was barely maintainable, and testability suffered a lot, so some problems remained unnoticed for a long time.
If you were afraid of that you could just make it possible to hide/unhide the detailed information just like with the ESC key during boot to switch between slideshow or kernel messages.
Not only "no", but "hell, no!". Seriously. We will no longer keep multiplying code execution paths; that makes code more error-prone, a lot harder to maintain and almost impossible to test. We need to find a viable compromise instead of catering to lots of fringe groups and pathological cases.
And displaying parallel operations is really not a problem. You can stack progress bars and restrict it to show e.g. only up to five of them to keep the screen clear.
Been there. Done that. Had to get rid of it again for various reasons; starting with limited screen space on an NCurses (virtual) terminal. This does not work; it only makes everything more nightmarish. It may sound harsh, but in the past, none of those people who suggested such "how hard can it be" solutions was ever there to fix any of those problems that are inevitable. They always left us alone with the problem when the answer to that question turned out to be "damn hard". ;-)
The solution you chose was the worst of all. Hiding information and keeping the user dumb and uninformed is not the way Linux works.
And you are really argueing "show less to avoid confusion when more parallel approach will be implemented"? Do you think users are silly and too stupid to bear more than one progress bar?
Nobody needs slideshows of release notes or other unimportant stuff.
Tell that to the people who make that stuff mandatory features.
What we need is information what's going on with the installation. You really destroyed a formerly extremly useful and informative GUI and should definitely consider bringing it back
No. It's gone.
(make it optional to show if you like).
No; no more code and execution path duplication. See above.
For now, watching the AY installation is as frustrating as watching a Windows or MacOS installation.
We always caved in to people demanding all kinds of compromises and support for even the most exotic scenarios and use cases. We kept adding options and modes. We made more and more stuff configurable. We kept adding buttons and other UI elements. We kept making the whole thing more and more flexible. We had to give in to product managers wanting to showcase their special $FEATURE_OF_THE MONTH, giving it more attention in the UI than it really deserved. All that stuff accumulated over the years and decades, and you can never get rid of any of it again. Never ever. Somebody will always start whining when you try it, and there will be huge discussions over non-issues. And you know what? That stuff gives rise to those with the "how hard can it be?" attitude to start a completely new, completely dumbed-down installer; and their stuff, as immature as it may be, is always praised to the highest heavens. Suddenly, it no longer matters what that new prototype of the month can really do; if it can really deliver on its promises, let alone all the use cases that we as the official SUSE installer simply have to support. None of those things ever came with a text mode compatible to even the most simplistic of terminal emulations (or even real terminals) like our NCurses mode. None of them ever could live with a vast range of screen resolutions. Do they support Chinese, Japanese, Korean, Arabic, Hebrew, Thai, Hindi with all their character sets and writing directions? Do they support LUKS, RAID, Btrfs with snapshots, iSCSI, FCoE? Do they support a serial console for rack-mounted servers? Do they support all the special stuff for the less mainstream architectures like ppc64, aarch64, s390? We have to do all that. Nobody cares how hard it is or what it means for maintaining the code, or even just for the most simplistic testing. Yet those simplistic prototypes are always used to bash YaST and the YaST team. So we have to innovate and simplify where and when we can. And that installation progress was one of those places; a cleanup was long overdue. Of course such a rewrite is never without problems. But we have to identify the areas that are really problematic and come up with fixes, not shoot down a whole concept yet again; and remain stuck with unmaintainable stuff with a lot of history and technical debt. So, if there is constructive criticism pointing out individual problems, by all means let's hear it. But a broadside trying to shoot down the new approach in general won't achieve anything. Still, as I wrote initially, don't get me wrong: Your feedback is very welcome. Kind regards -- Stefan Hundhammer <shundhammer@suse.de> YaST Developer SUSE Software Solutions Germany GmbH GF: Ivo Totev; HRB 36809, AG Nürnberg
Stefan, thank you very very much for this detailed answer! I do get your point and understand you didn't just change sth. because you thought it might be a funny idea but it was a well-discussed decision. Of course that doesn't help information junkies like me, but well. You arguments about complexitiy and support for different platforms and languages etc. are reasonable. And I have to accept you won't go back for all the reasons you mentioned. So after all you said about code complexity and path duplication, let me come up with a proposal which should be easy to implement and might be at least some fallback for people like me: maybe you could add a popup or window below the progress bar that is activated by some button or sth. and just tails /var/log/YaST2/y2log with a large buffer and a vertical scrollbar. It would be hidden by default, but if people click the "view logfile" button, they would see what's going on. You might add some filter so that you only see relevant stuff. That's what I did in the end to see what's going on, I just called "ssh <server> tail -f /var/log/YaST2/y2log |grep -o 'Executing.*'" and although it gives no progress per package, it shows at least the list of packages currently installed. Better than nothing, but doing it manually with ssh for parallel installations of several hosts is a bit troublesome, so having this in the gui would be way easier. Maybe this is something worth considering? cu, Frank -- Dipl.-Inform. Frank Steiner Web: http://www.bio.ifi.lmu.de/~steiner/ Lehrstuhl f. Bioinformatik Mail: http://www.bio.ifi.lmu.de/~steiner/m/ LMU, Amalienstr. 17 Phone: +49 89 2180-4049 80333 Muenchen, Germany Fax: +49 89 2180-99-4049 * Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. *
participants (15)
-
Ancor Gonzalez Sosa -
Andrei Borzenkov -
David Díaz -
Frank Steiner -
Imobach Gonzalez Sosa -
josef Reidinger -
José Iván López González -
Kenneth Wimer -
Ladislav Slezak -
Ladislav Slezák
-
Lukáš Krejza -
Neal Gompa -
shundhammer -
Srinidhi B -
Stefan Hundhammer