Re: boot banner project

> /dev/null <null_at_dnswatch.com> wrote:
>
>>> I think restructuring our userland boot message would be a good start.
>>> I'm
>>> not talking about the above proposal, even if I think it's nice (but a
>>> little bit too terse for me), I'm talking about rethinking the actual
>>> (since
>>> the new rc system) clutter.
>>>
>>> The 4.x startup looks structured (it could be improved to be more eye
>>> friendly, but the beauty lies in the eye of the beholder), while the 5+
>>> one
>>> is neither fish nor meat. It's a mixture of the 4.x one with the
>>> "Starting
>>> xyz" messages from the new system. Since we don't try to keep the new
>>> system
>>> diff friendly with the NetBSD source anymore, I think we could change
>>> it
>>> to
>>> fit our needs.
>>
>> Maybe this would be a better place for me to start
>> (assuming no objection(s)). I mean, it may turn out
>> the large majority of opinion is: boot-banner SUX! So
>
> If root is able to switch the boot-banner on/off, and as long as headless
> and
> serial-console enabled systems behave as usual, nothing should stop you
> from
> doing this project.
>
>> in either case; making what already exists more desirable/
>> funcional; seems the best place to start something. As
>> opposed to adding to something that might me better polished
>> up. What's more, I was thinking; what if the current settings
>> ( verbose/ terse ) were expanded and prettified(stylized).
>> Example: 3 settings;
>>
>> 1) no output: black, or blank screen until the prompt/ login.
>
> That's not a good option (from an usability point of view). You need at
> least
> some progress indicator, else an user will ask if the system freezed or
> not.
>
>> 2) terse:
>> a) only dumps warnings
>> b) dumps item at succesful load, or else failure message as returned by
>> failed object.
>>
>> 3) verbose:
>> a) raw (pretty much the way it is now but unify/ sanitize the messages
>> returned - (4.x ify?))
>> b) prettified
>> (example(s):
>>
>> mysql <loaded>
>>
>> or
>>
>> mysql <message returned upon load/ or load failure>)
>>
>> both <loaded> or <message> *could* be colorized.
>
> That's too much options IMHO ("less" is "more", you know? ;-) ). You need
> a
> progress indicator in 2), and you need the possibility to report errors in
> 1), so I think you can reduce it to
> a) progress indicator + error output
> b) raw (as is, or polished up)
> c) nice
>
> But since we don't have an option to shut up the kernel messages on boot,
> I
> think we don't need a).
>

I can see all your points. I'm just forming these concepts. So it's great
to hear others perspectives on this. It's easy to overlook details
sometimes.

> If you want to proceeed with this,

> you should move over to the freebsd rc mailinglist.
Could you expand on this? I don't know sbout that list.
Or you just attempting to get rid of me?

>
> Bye,
> Alexander.
>
> --
> http://www.Leidinger.net  Alexander _at_ Leidinger.net: PGP ID = B0063FE7
> http://www.FreeBSD.org     netchild _at_ FreeBSD.org  : PGP ID = 72077137
> If sex is such a natural phenomenon, how come there are so many
> books on how to?
> 		-- Bette Midler
>
>
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
>

-Chris H.
////////////////////////////////////////////////////
 If only Western Electric had found a way to offer
binary licenses for the UNIX system back in 1974,
the UNIX system would be running on all PC's today
rather than DOS/Windows.
////////////////////////////////////////////////////