Boot screen: Quiet or not?

[Mario Vukelic]

On Tue, 2007-10-09 at 23:04 -0700, Steve Lamb wrote:
>     How does that harm her?  

At the very least it confuses here into thinking something is wrong even
when it isn't. You may not have notice, but the raw boot messages are
often pretty ambiguous vor non-technical users.

>     Unless they're 400 miles away on the other end of the phone line and
> asking you for help.

1) Log in via ssh and change it. That's how support should work
2) As I said in my original post, of course it should show messages when
there is a need. If everything is alright, there is no need.

>     "Hi, son?  Uh, the linux box is acting up again.  Yeah, black screen, can
> you work with that?"  

Please try to read my posts before replying to them, it gets annoying
having to repeat that of course it should show messages when there is a
need.


>     Given the option of Slackware or Windows can we err on the side of
> Slackware?  

No, I hope not. We should err on the side of the Mac and improve on
that.  Slackware is a download away if yo want it.

> Trust me, Ubuntu is in no danger of drifting into Slackwaredom
> just because of 30s of scroll during a critical portion of the machine's
> operation.

It's not critical when everything is fine.

> The progress bar doesn't tell *me* why when they call me at
> 10pm when I'm relaxing from my day and trying to unwind so I can get to sleep.
>  The text *does*.  The text isn't for them, it is for *us*.

Of course it should show messages when there is a need.

>     It isn't a UI!  It is important diagnostic messages! 

Which are delivered to the user by a user interface, the screen. And
they are only important if anything goes wrong.


>  The UI is what comes
> after the phrase "Username: "

You have a too narrow notion of UI. If, for example, a new user cannot
get the Ubuntu installer to boot because e is incapable of changing the
boot sequence, what is this? It's a UI failure.

>  So how, exactly, does telling them to reboot the machines just so you can
> attempt to get at the error messages that should be present in the first place
> *good* diagnostic design?  It's not.

Of course it should show messages when there is a need.