LCDproc development and user support list

Text archives Help

[Lcdproc] LCDd, inetd, and Archeology (was: RE: Clients for dummies!)

Chronological Thread 
  • From: peter at (Peter Marschall)
  • Subject: [Lcdproc] LCDd, inetd, and Archeology (was: RE: Clients for dummies!)
  • Date: Sat, 22 Nov 2008 18:00:52 +0100


On Sunday, 16. November 2008, Gary R. Van Sickle wrote:
> That was my thought when I first found that out when writing my own client.
> Now, archaicness in-and-of-itself isn't necessarily a problem (or none of
> us would be using *nix!), but what is a problem is LCDd's run-time
> dependency on inetd. Is there a reason why LCDproc doesn't use unix domain
> sockets or named pipes or something else a little more local?

Please don't disseminate false information.

LCDproc does not depend on inetd.

How do you come to this observation.

> There are two primary use cases for LCDproc:
> 1. As a secondary display for some local system state information (or
> equivalently, some non-local state that has been obtained through other
> means and made local):
> [ ...]
> 2. As a primary display for "headless" and embedded systems:
> [ ...]
> I don't really consider the situation where LCDd is connected to by some
> outside agent over the network as a real use case. Just because one can do
> a thing doesn't mean it makes much sense, and in this case the ability to
> do this is more of a side-effect of the implementation that anything else.
> If this is intended to be a real use case, sending the info over the
> internet in-the-clear via telnet is probably not the best choice of IPC
> here either.

This is your personal opinion.
For me, the client-server architecture or LCDproc was the main reason to
use it and to develop for it.

What about having one display but multiple systems ?
E.g. a NSLU2 and another headless machine, both being on a trusted

> [...]
> In order to be all things to all people, It Would Be Nice(tm) if LCDproc
> had an architecture more like this:
> LCDd <-some_local_IPC_protocol-> telnet_interface_client_d
> <-current_LCDproc_client_language->
> current_LCDproc_clients_which_use_the_telnet_interface
> <-some_local_IPC_protocol->
> new_LCDproc_client_with_no_need_for_telnet_1
> <-some_local_IPC_protocol->
> new_LCDproc_client_with_no_need_for_telnet_2

Sorry, this is too terse for me to understand.

I am aware that the current protocol has a lot of disadvantages:
- cleartext, not encrypted
Yes, I want the network protocol ;-)
- no authentication
This should be in a network protocol.
- widget commands could get some updates
Here are some of the things that I consider unfortunate:
- the position of a widget should be determined when
defining it, so that when using it you do not need to
tell where to position it
- all widgets should have a size, that limits the output
- bar widgets should give their length in percent / per mille
instead of pixel columns
- ...

Unfortunately it is not possible to change it without breaking
compatibility with older clients.
That's why this will not happen within the 0.5.x series of


Peter Marschall
peter at

Archive powered by MHonArc 2.6.18.

Top of page