Elektrify LCDproc

--===============8061880135534833168==
Content-Type: multipart/signed; boundary="nextPart2857257.KzpAeLSdMW";
	micalg="pgp-sha256"; protocol="application/pgp-signature"


--nextPart2857257.KzpAeLSdMW
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"

Hello Everyone,

This news item describes the current status of Elektrify LCDproc.
It also can be read at https://www.libelektra.org/news/elektrify-lcdpro=
c

> LCDproc is a piece of open source software that displays real-time
> system information from your Linux/*BSD box on a LCD.

LCDproc's [website](http://lcdproc.omnipotent.net/) is a bit outdated
but LCDproc itself is now well-maintained on
[GitHub](https://github.com/lcdproc/lcdproc) and had a
[release recently](https://github.com/lcdproc/lcdproc/releases).

Like in many projects, it invented its own configuration access and
INI parser which did not evolve with the needs of the project.  As a
consequence inconsistencies and code duplication spread over the source=
.
For example, the LCDproc configuration access does not support values
that represent display's size (such as `20x4`).  Thus every LCDproc's
module has its own parsing code for such values.

Some days ago (16.03.2017), we met with Harald Geyer and discussed the
current situation.  We decided that we will elektrify LCDproc and remov=
e
all the configuration access and parsing code within LCDproc.
To **elektrify** an application means to change the application so that=
 it=20
uses LibElektra afterwards.


## Goals

We formulated three goals:

1. We (Elektra Initiative, mainly Thomas Waser) remove as much code
   as possible from LCDproc's code base.
2. Users of LCDproc should be able to use `LCDd.conf` as they use it no=
w.
3. We avoid the current duplications of configuration specifications.
   (Currently in `LCDd.conf`, the docbook, in code checking the limits,=

   and the default parameter in the code.)

Nice-to-have is:

=2D Safe updates: `make install` should not break the current `LCDd.conf`=
.
  (As it is already done in Debian.)
=2D The robustness of LCDproc on misconfiguration should be improved
  (Thomas Waser writes the specification).
=2D Automatic reloading of the daemon when using Elektra to update=20
configuration.
  (Manual `SIGHUP`-signals will work in any case.)
=2D Have physical units with metric prefix like `500ms` for `0.5s` (secon=
ds).

Possible limitations are:

=2D We break support for systems that only have very old compilers.
=2D The `-c` option to specify a different configuration file is
  against the abstraction Elektra should deliver.  We might create a
  [wrapper script]
(https://github.com/ElektraInitiative/libelektra/issues/1416)
  that emulates `-c` via mountpoints.
=2D LCDproc will depend on the yet-to-be-released
  [0.8.20](https://github.com/ElektraInitiative/libelektra/milestone/11=
).
  We will delay the 0.8.20 release until all parts for LCDproc are test=
ed and=20
ready.

In any case, the [advertised benefits of Elektra](https://www.libelektr=
a.org)
will automatically apply (incomplete list):

=2D Global key database: you can connect other configuration files with t=
he
  LCDproc's configuration and validation.
=2D Allows users to easily modify the specifications, for example to have=
=20
  different command-line options, or support for environment variables.=

=2D [Profile support](https://www.libelektra.org/plugins/profile): Having=
=20
  multiple complete configuration settings you can easily choose from.
  (thanks to Thomas Waser)
=2D Introspectibility: you can check with `kdb`-tool which configuration
  settings LCDproc will receive.
=2D Other configuration file formats can be used instead, e.g. JSON or XM=
L.
  (Only if wanted as personal preference, by default INI will be used t=
o
   remain compatibility with `LCDd.conf`.)
=2D Easy migration paths to use other configuration file formats such as =
YAML
  as default in future. (thanks to Ren=C3=A9 Schwaiger)
=2D Elektra's tool can be used to configure LCDconf, including:
 - `kdb set` to modify individual settings within scripts and validatio=
n.
 - `kdb editor`, which spawns your favourite editor but validates
   the configuration file before writing it out.
 - `kdb qt-gui`, the Qt GUI (thanks to Raffael Pancheri).
 - The web UI of Elektra (thanks to Daniel Bugl).
=2D Elektra's website can be used to share LCDproc's configuration files,=

  and you can use the [curlget plugin]
(https://www.libelektra.org/plugins/curlget)
  to mount files from the website. (thanks to Marvin Mall)
=2D You can use Shell, Python, or Lua to write small scripts that are exe=
cuted=20
  on configuration access.
=2D Elektra allows you to directly read and write from git
  using the [git plugin](https://www.libelektra.org/plugins/gitresolver=
).
  (Even if `LCDd.conf` is not checked out, thanks to Thomas Waser)
=2D We extensively [test](https://www.libelektra.org/devgettingstarted/te=
sting)
  Elektra with modern techniques such as fuzzing.


## Validation

Instead of `if`s within the code, we will use SpecElektra for validatio=
n.
[SpecElektra](https://www.libelektra.org/manpages/elektra-glossary)
is a configuration specification language that allows us to describe
which configuration is valid.

This specification will be installed as part of LCDproc to
`/usr/share/elektra/specifications`.
It uses the [metadata](https://www.libelektra.org/docgettingstarted/met=
adata)
as defined by the plugins to validate configuration changed via
Elektra.

For broken installations or when executing LCDproc from the source
repository, there is also a built-in specification.  The specification
will only be used if the installed one cannot be found.

Thus the configuration validation specification is a normal configurati=
on
file also integrated in Elektra, also the specification can be introspe=
cted:
useful for system administrators who want to know about valid entries, =
but
also for tools like our newly developed web-UI by Daniel Bugl.

The web-UI automatically restricts the interface so that only valid
entries can be entered.  For example, if you should enter a boolean,
only a check box is presented to you.

=2D For more information about validation, see the [tutorial]
(https://www.libelektra.org/tutorials/validate-configuration)


## Code Generation

We (mainly Dominik Hofer) are currently developing
[a high-level API](https://www.libelektra.org/decisions/high-level-api)=
,
whose first user will be LCDproc.  In this API, we will make sure durin=
g
compilation, that configuration access is done correctly.

This is especially useful when configuration settings get renamed.
Then all places where out-dated configuration settings are used will fa=
il to=20
compile.

In particular using code generation developers do not need to use strin=
gs
to refer to configuration settings and they get easy-to-use enums consi=
stent
with the configuration specification.

Furthermore, code generation will make sure that a specification (and d=
efault=20
configuration settings)
will be found even if no `/etc` or no `/usr` is found.

We also found that we cannot use code generation everywhere.
In generic access code, code generation obviously is limited.

=2D For more information about code generation, see the [tutorial]
(https://www.libelektra.org/tools/gen)


## Risks

Understandably, users might be concerned that such a change will not wo=
rk or=20
create
problems in the future. Here we will discuss some of the concerns.

> Elektra might be discontinued.

From=20history perspective, Elektra received steady development since 200=
4.
Elektra is a FLOSS project and welcomes everyone to join. In the last
years several people did, with an increasing number per year.
Currently following people are working on substantial new features in E=
lektra
(sorted by first name):

=2D Armin Wurzinger: Quality Improvements
=2D Bernhard Denner: [Puppet Module]
(https://github.com/ElektraInitiative/puppet-libelektra)
=2D Daniel Bugl: [WebUI](https://www.libelektra.org/tools/web)
=2D Dominik Hofer: [the high-level API]
(https://www.libelektra.org/decisions/high-level-api)
=2D Kurt Micheli: Order Preserving Minimal Hash Map
=2D Markus Raab: Maintainer
=2D Michael Zehender: Quality Improvements
=2D Mihael Pranji=C4=87: mmap plugin
=2D Peter Nirschl: [crypto plugin](https://www.libelektra.org/plugins/cry=
pto)
=2D Ren=C3=A9 Schwaiger: YAML plugin
=2D Sebastian Bachmann: Shell Completion
=2D Thomas Waht: Notification
=2D Thomas Waser: Validation and Transformations of Configuration
=2D Vanessa Kos: Misconfiguration Bug Database

Obviously, there are many more casual contributors.

Elektra has a large set of [automated tests](https://build.libelektra.o=
rg)
and only a small amount of technical dept. Elektra has no required exte=
rnal
dependencies except libc. So without internal changes, only minimal=20
maintenance
cost is required.


> Elektra is unfinished.

Technically this is true: we did not reach
[1.0](https://git.libelektra.org/milestone/12).
We are, however, on track to reach this goal within this summer.
Now is the best time to join because we can provide more support
and are more flexible for changes and wishes.

Some [time ago](https://www.libelektra.org/news/2016-06-14_0.8.17.md) w=
e asked=20
in a survey in
which direction Elektra should develop. Most open issues are (in)direct=

responses from this wanted direction.

Some plugins are experimental or proof-of-concept, but they are clearly=

marked as such.


> It seems a bit to me like [xkcd: Standards](https://xkcd.com/927/).

Elektra does not invent a new configuration file format nor new standar=
ds
where to store configuration files but abstracts over these issues.


> Elektra not being available in my distribution.

For the following Linux Distributions Elektra 0.8 packages are availabl=
e:

 - [Openwrt](https://github.com/openwrt/packages/tree/master/libs/elekt=
ra) (by=20
Harald Geyer)
 - [Fedora](https://admin.fedoraproject.org/pkgdb/package/elektra/)
 - [Gentoo](http://packages.gentoo.org/package/app-admin/elektra)
 - [Arch Linux](https://aur.archlinux.org/packages/elektra/)
 - [Debian](https://packages.debian.org/de/jessie/libelektra4)
 - [Ubuntu](https://launchpad.net/ubuntu/+source/elektra)
 - [OpenSuse](https://software.opensuse.org/package/elektra)
 - [PLDLinux](http://sophie.zarb.org/rpms/763d9e52beefaa15b1363d11d836b=
65c)
 - [LEDE](https://lede-project.org/packages/pkgdata/libelektra-core?s[]=
=3Delektra)
 - [Linux Mint](https://community.linuxmint.com/software/view/elektra-b=
in)

See [INSTALL](https://www.libelektra.org/docgettingstarted/installation=
)
for the complete and up-to-date list.


> If Elektra does not take off and achieve world dominance,
> will we be worse off than before?

Making sure that projects will not be worse off is what we did the last=

years: Not only offer an API and wait for world dominance but to offer
an implementation that can compete with any configuration library out
there. We are not completely there yet (there are some details where
specific other libraries are better than Elektra in specific points)
but these are not points that the current configuration system of
LCDproc supports (not even close). And the libraries that can compete
with Elektra have a completely different level on which dependencies
they have: Elektra is the only one only requiring libc.

> Do we retain the old way of configuring things,
> i.e. manually editing a ini file in /etc?

Absolutely, you can think of libelektra as a small library in C that
reads a configuration file and returns a data structure if you do not
use any of its advanced features.

> Do we retain the old way reloading/restarting the system service?

Elektra does not interfere with restarting. It is a passive library.
It provides some techniques for reloading but they are optional (but we=

recommend that you keep the in-memory and persistent configuration in
sync via notification).

For more information, see the [FAQ]
(https://www.libelektra.org/manpages/elektra-faq).


## Win-Win

We can both profit from it:

1. For LCDproc it will be a simplification of code while getting many m=
ore=20
tools.
2. For Elektra it will improve its adoption and packaging.

For oyranos it already worked well on both sides, see our discussions i=
n the=20
issue tracker, for example [#1134](https://issues.libelektra.org/1134).=


If you also maintain an free or open source (FLOSS) project with an out=
=2Ddated=20
configuration system, please contact us.

Obviously, we cannot fully port every FLOSS project ourselves, instead =
we will=20
handle requests on a first come, first serve basis.
Earlier projects will also have an higher impact on the feature set of=20=

Elektra, thus you will less likely need to implement your own plugin.


## See also

=2D Progress can be viewed [here](https://git.libelektra.org/projects/7)
=2D We discussed about alternatives to Elektra [here]
(https://issues.libelektra.org/1266).

best regards,
=2D-=20
Markus Raab            https://www.libelektra.org
Technische Universit=C3=A4t Wien       [email protected]
Institut f=C3=BCr Computersprachen           Phone: (+431) 58801/185185=

Argentinierstr. 8, 1040 Wien, Austria     FAX: (+431) 58801/18598

DVR 0005886
--nextPart2857257.KzpAeLSdMW
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIVAwUAWNAUtUyVgPULLw3cAQiiMw//VXeDunn45EkCqbEjzCQnuAyFX7XfZi4+
s0DNGNqvHsRc2I2BqDbDR8TLYCTfIYijL1AcmSeoJNe3HbLL3k0WYQh+pD1nQTIl
ZL40ahd++5mDfQ6P6iN5daFZMt7n8f2QCC5CM7pf/JtuT/0EsZOPfdocbMxMftQz
l8aCVWilJ/jDgJMqhnFc/nvksgcjFwClWpkKI6yx50t4aAwEgt7JON+CZDKOeRwM
2RVa15szvJyZRkfWPanaqT54PabhkPwuS3XW3RDJwFjugQuXQuTwRMUJURSf9O1X
Gpqw76SDB8BPIuWUl1Y0stIpe6NdfupwFD414c7daRzW+hbnyn8EbmyCcceJ3QDa
4ywUUoKPHIGfaqsb1FH2efZo1W+WsiiSWWg/XNfVfS9VOMtPJoyoqblSq4QngEvh
tmO4oCpfw+iuENU/4ReMwMrxSuChGiOfoBbvjlE1JCHnYz5xOQZD7+jsZiktJedg
DD0XVBEIJGbF1UTyqiO8AJD2x9c81Hkan/vNfMwWa3BzqgOw3bHR7Tic0t8JFrzk
Yuyj678hHq+7vuSfp4bfawht9vrDKYsZ3alFcZUhkLJpoxUQp0DN4zgf93xPtbOI
mZ19QO7UxuGJAvxO65g5WsD0tlOLMZyYNRbL8yBLGn84T3PWT0iUWyhkxIQJK9sG
+9Daf2hZ8nA=
=P5kC
-----END PGP SIGNATURE-----

--nextPart2857257.KzpAeLSdMW--



--===============8061880135534833168==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
--===============8061880135534833168==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Registry-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/registry-list

--===============8061880135534833168==--