Re: boot images/logos/splashes (one more idea)

Khimenko Victor (
Thu, 14 May 1998 15:10:25 +0400 (MSD)

MH> At 01:31AM on Thu, May 14, 1998, Khimenko Victor <> sent:
MH> > Of course this could be used only on appropriate terminals. There are must be
MH> > way to suppres "coloring"...
MH> Yes, you need to detect terminal capabilities and then use them appropriately.
MH> Ie, your kernel needs half a meg of termcap built into it, and probably most
MH> of libtermcap also. And this is only for text! Let alone attempting to
MH> display a graphical boot logo!
MH> I doubt Linus would be open to such a waste.
AFAIK here was talk ONLY about ONE case: terminal is NOT separated part of
computer, but instead we have Linux on some PC (IBM PC with VGA, Mac with
what's attached to Mac by default, etc.)... In this case you does not need
termcap or libtermcap -- you need only info about PC hardware itself (and not
so much, by the way)...

MH> > Here is talk not about case where Linux is running with real terminal attached.
MH> > Less then 1% of Linux boxes are installed this way !!! Talk is about "standard"
MH> > mode -- you have Linux on Desktop computer...
MH> Interesting statistics, where did you gather this information? Because I know
MH> of places where 100% of the linux boxes are used this way. If I take my group
MH> of close friends for example, there are 5 people, 8 linux boxes (and a bunch
MH> of win95 and Macintosh), and in terms of percentages - 50% have no terminal
MH> attached, one has a mono serial terminal and a 21" 1bpp X terminal, one has
MH> (I think) a 2Mb SVGA card but I'm not certain, only the last two are pc
MH> workstations.
1% is just approximation. I was NOT talking about situation where Linux box is
not attached to monitor and accessed only from X-terminal (I am seen a lot of
such compuers myself :-)... I am talking ONLY about case where initial bootup
messages will go not to VGA card (and may be to /dev/null from there since
VGA Card is not attached to nothing -- in this case there is no difference
between standard bootup messages and version with Logo -- you could not see
them anyway :-) -- even in you example only one computer has serial terminal
where you could see bootup messaged (you could not see bootup messages on
X-terminal :-)

MH> > Oops. YES, OF COURSE. If you have non-standard system (for example with
MH> > serial startup console, or embeded system, or ...) you does not want or need
MH> > such Boot Logo. For server without monitor attached this is also useless.
MH> > But this is rare cases anyway (important, yes, but rare).
MH> Funnily enough, this "rare" case constitutes 75% of the computers running
MH> linux in my group of close friends. 75% doesn't sound "rare" to me.
MH> And I'd be quite surprised if we were extra-ordinary linux users.
75% Linux boxes use serial terminals on which you could see bootup messages ?

MH> > > You seem to suggest that a root prompt will freak out the users. But what
MH> > > system administrator in their right mind is going to let their gumby users
MH> > > see a root shell prompt on a daily basis?
MH> > What else prompt he will see after installing RedHat, Debian, Slackware, etc,
MH> > etc. just now ?
MH> The system administrator will see the root prompt, the user won't. My point
MH> still stands valid.
Unfortunatelly in many cases "system administarator" could be not brave enough
to manage command line interface well. Now this is rare cases but when Linux
will be ready to use for novices this will be usual situation...

MH> > > I just had this really horrible thought that you're actually considering
MH> > > giving these GUI users root access to their workstations!
MH> > Unfortunatelly you could not even install a lot of stuff without root access :-(
MH> Then either those programs are critical system components (such as sysvinit,
MH> login, X11, etc) in which case the system administrator will be installing
MH> them, or the programs themselves are broken.
MH> There is no reason why an ordinary userspace program cannot be installed by
MH> a regular user unless that program is either broken in design, or system
MH> access policy dictates that ordinary users won't have access to a compiler.
MH> (in the latter case, they could try finding a pre-compiled binary of the
MH> program anyhow and still install it anyway).
Oh, yes, you could change most of programs to work without root access... This
is right. But it's FAR MORE complex task then to install .rpm (or .deb) with
graphic tool. Novice will be able install .rpm (from root account, of course),
but if you want install program without root access you must have A LOT OF
more about Linux and program :-((

You strip out one VERY important part of my letter: Linux is developed as
"desktop system". This means that in some point Linux will be used by novices.
For now most Linux "system administrators" are geeks (like me and you :-), but
what about time when most of "system administartor"'s will be peoples from
Windows world who just want to have OS (and programs) to work not to constant
reinstall ? Yes, this sutuation will not be tomorrow or even in this year, but
this is not means that you could assume that this is will never happens...

MH> > > Come to think of it, the bootup sequence you describe above is actually very
MH> > > bad since important information could scroll up unretrievably into the mini
MH> > > window.
MH> > This is depends from size of screen. If you'll use 376x564 screen and 6x8 font
MH> > this "mini window" will be more in size then current fullscreen view...
MH> Yes, but that assumes there is a console attached that is capable of displaying
MH> that particular resolution. You just cannot blindly assume these things!
We could. Since most PC's are. This resolution could be used on ANY STANDARD
VGA (or SVGA) Card. And this is not so diffucult to check type of card before
using this graphic mode. Of course SparcLinux, AlphaLinux, etc could not have
VGA and I am not talking about them just now. But most of PC's now has
VGA-compatible cards...

MH> Even if this feature could be implemented tidily, you still end up with the
MH> problem of inconsistent bootup sequences across linux boxes. Some will boot
MH> like now, some will have this multiple scrolly window thing in a 376x564 screen,
MH> some will be displaying graphics, some will have abbreviated regular bootup
MH> messages... ugh.
This is may be most important point in your message...

MH> And it'll also cause problems logging bootup information
MH> unless dmesg is rewritten to handle each case and output a generic log format.
Oops. What a hell ? Of course strong point is to have messages stored for dmesg
in more or less current state (may be messages unification will be good :-)
This way in most cases where system is booted but not working properly you'll
use dmesg output and all will be fat and happy... Only information ON SCREEN
must be rearranged...

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to