Re: The alternative for "update-alternatives" ---> libalternatives
Am 21.09.21 um 09:47 schrieb Danilo Spinella:
libalternatives is imho a big improvement over update-alternatives.
But the question remains: what about performance?
If I have a small program that is called in a loop, is performance severely hampered?
I.e. how does the following
a=`cat <
Is there any plan to upstream its support? I think the Open Source ecosystem would greatly benefit from doing so and we wouldn't have to maintain libalternatives support for the packages. Plus, I am a big fan of upstreaming and letting the spec file just run make && make install.
Let me know if you need any help regarding this.
Regards, Danilo
On Mon, 2021-09-20 at 09:19 +0200, Stefan Schubert wrote:
Hi,
most of you are already familiar with the usage of update- alternatives. Update-alternatives, at its core, is a symlink management system. This system is then mostly used as means for administrators of a system to select a default application. For example, if we have vim or emacs installed, the admin can then make one accessible as an editor application. Update-alternatives manages these tasks by symbolic file links which has worked out, that it could become quite instable in older updated systems. Adam Majer has established a new concept how to handle the update-alternatives tasks: libalternatives Libalternatives does not use file links anymore but little configuration files which is much more stable and quite easy to handle by the administrator. Have a look to https://github.com/openSUSE/libalternatives for more information. One additional benefit of libalternatives is that it does not create entries in the /etc directory anymore. In the future the /etc directory will be used for entries/changes ONLY which have been done by the administrator and do not belong to packages or have been created by package installation.
I have already switched about 40 packages to the new libalternatives which we need around MicroOS and have submitted it to factory.
This list includes a lot of python packages. Python packages are using nice RPM macros for handling update-alternatives stuff. Currently the fixes are made manually in the spec files and it will not be done by macros anymore. I have done this step at first in order to get a feeling what is needed for using/updating these macros at first. Now I will patch the alternatives macros or will write new one in order to simplify it again. And yes, I will update the regarding python packages again. So please, do not panic :-)
Please inform us if you have any comments, suggestions or even doubts.
Greetings Stefan
-- ********************************************************************* ********** Stefan Schubert e-mail: schubi@suse.de --------------------------------------------------------------------- ---------- SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nürnberg Germany
(HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer
Am 21.09.21 um 10:47 schrieb Manfred Schwarb:
Am 21.09.21 um 09:47 schrieb Danilo Spinella:
libalternatives is imho a big improvement over update-alternatives.
But the question remains: what about performance? If I have a small program that is called in a loop, is performance severely hampered?
I.e. how does the following a=`cat <
time -c "$a" >/dev/null
time bash -c "$a" >/dev/null of course. Sorry.
perform with libalternatives in contrast to /usr/bin/gawk?
Is there any plan to upstream its support? I think the Open Source ecosystem would greatly benefit from doing so and we wouldn't have to maintain libalternatives support for the packages. Plus, I am a big fan of upstreaming and letting the spec file just run make && make install.
Let me know if you need any help regarding this.
Regards, Danilo
On Mon, 2021-09-20 at 09:19 +0200, Stefan Schubert wrote:
Hi,
most of you are already familiar with the usage of update- alternatives. Update-alternatives, at its core, is a symlink management system. This system is then mostly used as means for administrators of a system to select a default application. For example, if we have vim or emacs installed, the admin can then make one accessible as an editor application. Update-alternatives manages these tasks by symbolic file links which has worked out, that it could become quite instable in older updated systems. Adam Majer has established a new concept how to handle the update-alternatives tasks: libalternatives Libalternatives does not use file links anymore but little configuration files which is much more stable and quite easy to handle by the administrator. Have a look to https://github.com/openSUSE/libalternatives for more information. One additional benefit of libalternatives is that it does not create entries in the /etc directory anymore. In the future the /etc directory will be used for entries/changes ONLY which have been done by the administrator and do not belong to packages or have been created by package installation.
I have already switched about 40 packages to the new libalternatives which we need around MicroOS and have submitted it to factory.
This list includes a lot of python packages. Python packages are using nice RPM macros for handling update-alternatives stuff. Currently the fixes are made manually in the spec files and it will not be done by macros anymore. I have done this step at first in order to get a feeling what is needed for using/updating these macros at first. Now I will patch the alternatives macros or will write new one in order to simplify it again. And yes, I will update the regarding python packages again. So please, do not panic :-)
Please inform us if you have any comments, suggestions or even doubts.
Greetings Stefan
-- ********************************************************************* ********** Stefan Schubert e-mail: schubi@suse.de --------------------------------------------------------------------- ---------- SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nürnberg Germany
(HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer
On Tue, Sep 21, 2021 at 11:01:46AM +0200, Manfred Schwarb wrote:
Am 21.09.21 um 10:47 schrieb Manfred Schwarb:
But the question remains: what about performance? If I have a small program that is called in a loop, is performance severely hampered?
Your bottleneck will be an additional exec() call. If that is a signifiant overhead in the execution path, then your execution path already had it as a significant overhead. But I would not recommend doing things like abstracting /bin/sh in this manner. Symlinks still have their place. - Adam
Am 22.09.21 um 10:18 schrieb Adam Majer:
On Tue, Sep 21, 2021 at 11:01:46AM +0200, Manfred Schwarb wrote:
Am 21.09.21 um 10:47 schrieb Manfred Schwarb:
But the question remains: what about performance? If I have a small program that is called in a loop, is performance severely hampered?
Your bottleneck will be an additional exec() call. If that is a signifiant overhead in the execution path, then your execution path already had it as a significant overhead.
But I would not recommend doing things like abstracting /bin/sh in this manner. Symlinks still have their place.
OK, then I misunderstood something. I thought the intention was to replace all alternatives handling with libalternatives, i.e. also for potentially often called binaries as ksh or awk.
- Adam
On Wed, Sep 22, 2021 at 10:52:01AM +0200, Manfred Schwarb wrote:
Am 22.09.21 um 10:18 schrieb Adam Majer:
On Tue, Sep 21, 2021 at 11:01:46AM +0200, Manfred Schwarb wrote:
Am 21.09.21 um 10:47 schrieb Manfred Schwarb:
But the question remains: what about performance? If I have a small program that is called in a loop, is performance severely hampered?
Your bottleneck will be an additional exec() call. If that is a signifiant overhead in the execution path, then your execution path already had it as a significant overhead.
But I would not recommend doing things like abstracting /bin/sh in this manner. Symlinks still have their place.
OK, then I misunderstood something. I thought the intention was to replace all alternatives handling with libalternatives, i.e. also for potentially often called binaries as ksh or awk.
Which then brings the question why do it at all? Having one altertnatives system is better than two. Thanks Michal
On Thu, 2021-09-23 at 11:14 +0200, Michal Suchánek wrote:
OK, then I misunderstood something. I thought the intention was to replace all alternatives handling with libalternatives, i.e. also for potentially often called binaries as ksh or awk.
Which then brings the question why do it at all?
Having one altertnatives system is better than two.
Right. "alternatives --set alternatives libalternatives" sounds like genuine fun :-) But using one alternatives system for one set of options and the other for others sounds even crazier. Martin
Hello, On Wed, 22 Sep 2021, Adam Majer wrote:
On Tue, Sep 21, 2021 at 11:01:46AM +0200, Manfred Schwarb wrote:
Am 21.09.21 um 10:47 schrieb Manfred Schwarb:
But the question remains: what about performance? If I have a small program that is called in a loop, is performance severely hampered?
Your bottleneck will be an additional exec() call.
Nope. It execve's a specific binary and to find out which it needs to open, read and parse all the associated config files on each execution. That might still not pose a significant problem, but that needs to be measured instead of just be hoped upon. (Generally I do like the libalternatives approach, but maybe not for /bin/sh, as you say). Ciao, Michael.
On Wed, Sep 22, 2021 at 01:31:11PM +0000, Michael Matz wrote:
Hello,
On Wed, 22 Sep 2021, Adam Majer wrote:
On Tue, Sep 21, 2021 at 11:01:46AM +0200, Manfred Schwarb wrote:
Am 21.09.21 um 10:47 schrieb Manfred Schwarb:
But the question remains: what about performance? If I have a small program that is called in a loop, is performance severely hampered?
Your bottleneck will be an additional exec() call.
Nope. It execve's a specific binary and to find out which it needs to open, read and parse all the associated config files on each execution.
That might still not pose a significant problem, but that needs to be measured instead of just be hoped upon. (Generally I do like the libalternatives approach, but maybe not for /bin/sh, as you say).
Yes, I believe that it's a little heavy for /bin/sh because it happens on *every* execution. This adds up if you put it on 1m servers and run them for a year. And there is no appreciable benefit for doing this (at least I can't imagine one). But in general, the overhead seems to be the exec call. I just did a small benchmark that just execs /bin/true either directly or via /bin/alts and it's as expected. https://gist.github.com/AdamMajer/89e1402d26024f5ebddb25d19d2f0890 The main benefit for libalternatives over update-alternatives is that each user can override the default. Another is that the selection is not fragile -- you can snapshots of / and restore /etc and /home from a different time and things will not fall apart like with update-alternatives. The negative is mostly that extra exec() overhead (and if you ever find it's significantly more in some scenario, it's a bug :). Another issue is it's not immediately clear *what* you are running since execution depends no the argv[0] and config file and not target binary of a symlink. This is an issue with things like AppArmor. - Adam
On 2021/09/24 14:02:21 +0200, Adam Majer wrote:
On Wed, Sep 22, 2021 at 01:31:11PM +0000, Michael Matz wrote:
Hello,
On Wed, 22 Sep 2021, Adam Majer wrote:
On Tue, Sep 21, 2021 at 11:01:46AM +0200, Manfred Schwarb wrote:
Am 21.09.21 um 10:47 schrieb Manfred Schwarb:
But the question remains: what about performance? If I have a small program that is called in a loop, is performance severely hampered?
Your bottleneck will be an additional exec() call.
Nope. It execve's a specific binary and to find out which it needs to open, read and parse all the associated config files on each execution.
That might still not pose a significant problem, but that needs to be measured instead of just be hoped upon. (Generally I do like the libalternatives approach, but maybe not for /bin/sh, as you say).
Yes, I believe that it's a little heavy for /bin/sh because it happens on *every* execution. This adds up if you put it on 1m servers and run them for a year. And there is no appreciable benefit for doing this (at least I can't imagine one).
But in general, the overhead seems to be the exec call. I just did a small benchmark that just execs /bin/true either directly or via /bin/alts and it's as expected.
https://gist.github.com/AdamMajer/89e1402d26024f5ebddb25d19d2f0890
The main benefit for libalternatives over update-alternatives is that each user can override the default.
For this I use a link in my personal ~/bin/ or simply an alias in my shell
Another is that the selection is not fragile -- you can snapshots of / and restore /etc and /home from a different time and things will not fall apart like with update-alternatives.
This as well suppose that the "alt" binary never fails to parse an "always" existing configuration for the specific program ;) Maybe it would be an idea to *set* a symbolic link at the first parsing of the configuration below /run/libalternatives/ ... then the next execution could follow *this* link ...
The negative is mostly that extra exec() overhead (and if you ever find it's significantly more in some scenario, it's a bug :). Another issue is it's not immediately clear *what* you are running since execution depends no the argv[0] and config file and not target binary of a symlink. This is an issue with things like AppArmor.
The problem with apparmor and SELinux is a major one, that it might be that the "alt" binary has not only to parse the configuration but also set the context. And this seems to very useful if given in the configuration as well if required. Werner -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr
participants (6)
-
Adam Majer -
Dr. Werner Fink -
Manfred Schwarb -
Martin Wilck -
Michael Matz -
Michal Suchánek