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