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 <[email protected]>
YaST Developer
SUSE Software Solutions Germany GmbH
GF: Ivo Totev; HRB 36809, AG Nürnberg
