[Splashy-devel] Commit UNIX sockets

[Luis]

On 8/17/06, Otavio Salvador <otavio at debian.org> wrote:
> Tim Dijkstra <newsuser at famdijkstra.org> writes:
>
> >> Can we do that without breaking any policy?
> >
> > Yes we can, we should just conflict with usplash because they install
> > the same file, but other then that, I think we're OK.
>
> There's a virtual package that every userspace-bootsplash will provide
> and conflict against it. That way we avoid to have any other together.
>
> Current Debian SVN has it already implmented.

This is exactly the question I needed an answer for. Good!

I agree with Otavio that Splashy's code should not be made more
complex by adding the functions that a "client" should be doing. And
if we use the lsb_* functions, we can avoid writing a client at all
(which is exactly the proof of concept scripts that Tim already
committed. Great stuff).

I'm also worried about the many BSD users out there, but, we will find
solutions for updating the progressbar once Splashy is rock solid in
Linux.

This is the way I see the whole Splashy idea:

Splashy itself - very simple daemon whose only concern is to manage
/dev/fb0 (main screen). It knows how to "listen" for commands from
some interface (sockets now. FIFO previously. etc...)

splashy_update - the "client helper" so that users can quickly write
their own clients and be able to talk to Splashy (daemon).

Some glue in the form of scripts - a collection of script that "knows"
about the system: how many scripts are to be executed during boot?
what should be avoided (time-outs to Splashy)? what to do when some
other program wants to use the main screen (X, gdm, xdm, etc)? and
code to be able to read the console commands, when should we go into
"verbose mode", what to do when a "fail" "error" or something similar
is found, what to do when fsck is checking the disk for failures or
what have you?

The "glue" part of Splashy is broad. Right now Splashy is attempting
to read the console messages by itself, but, perhaps this is something
that should be removed and a circular buffer be implemented instead
(one that will be displaying the strings that the "print" command
sends to Splashy). This also means that Splashy should have another
command that tells it to switch to the verbose mode image ("image"
command as discussed in the meeting. That's actually very simple to
implement)

Keep these ideas in mind for next meeting. For now, let's focus on
getting the initramfs problem ironed out and the other bullet points
that were agreed upon on our first IRC meeting ever [1].

At this rate we will be "done" with Splashy 0.2 in no time ! (yes, we
are skipping odd number releases remember?)


[1] http://splashy.alioth.debian.org/wiki/doku.php?id=news

-- 
----)(-----
Luis Mondesi
*NIX Guru

Kiskeyix.org

"We think basically you watch television to turn your brain off, and
you work on your computer when you want to turn your brain on" --
Steve Jobs in an interview for MacWorld Magazine 2004-Feb

No .doc: http://www.gnu.org/philosophy/no-word-attachments.es.html