Re: [systemd-devel] why are the systemd binaries so huge and can we do something about that?

[Lennart Poettering]

On Tue, 17.05.16 18:11, Michael Biebl (mbi...@gmail.com) wrote:

> I have to add, I don't quite understand, why the convenience libs are
> split up like this:

explained some in the other mail. To add to this:
> 
> 
> > libbasic.la
> > libshared.la
> > libfirewall.la

this one is separate as it pulls in the netfilter libs and we
don'twant that dep on all binaries.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] why are the systemd binaries so huge and can we do something about that?

[Lennart Poettering]

On Tue, 17.05.16 18:09, Michael Biebl (mbi...@gmail.com) wrote:

> 2016-05-17 10:36 GMT+02:00 Lennart Poettering :
> > On Mon, 16.05.16 04:24, Michael Biebl (mbi...@gmail.com) wrote:
> >
> >> Hi,
> >
> >> Any ideas, why simple tools like loginctl, busctl, hostnamectl require 
> >> 300K+ ?
> >> What's up with systemd-analyze?
> >
> > it embedds much of PID1's logic actually, in order to do unit file
> > checking.
> >
> >> Could we move more common functionality into a shared, private library
> >> to counter the constant growth?
> >
> > This has been discussed, and yeah, this should be a good thing to
> > do. It's just a matter of doing it. A shared, but explicitly private
> > library would be good. I figure it should be built from the stuff in
> > src/shared and src/basic. This would mean it won't help in the
> > systemd-analyze in case, but I think it's OK, given that that's a
> > debugging tool.
> 
> Looks like this is not quite that simple. I fiddled with this for a
> bit without any success.
> We have quite a bit of noinst libs atm [1].
> Would you turn all those into pkglib_LTLIBRARIES?
> Merge them into a single lib (or maybe two: libudev-internal and
> libsystemd-internal?)

Well, again, I'd really focus on basic and shared and turn them into
one lib. Stuff like libcore is only used by PID 1 and systemd-analyze
and hence not worth sharing I would say. And things like
libmachine-core only exists in order to make test cases that test the
machined sources easy. The library is used only by a single binary
that is actually also installed.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] why are the systemd binaries so huge and can we do something about that?

[Michael Biebl]

I have to add, I don't quite understand, why the convenience libs are
split up like this:


> libbasic.la
> libshared.la
> libfirewall.la
> libcore.la
> libsystemd-internal.la
> libsystemd-network.la
> libudev-internal.la
> libudev-core.la
> libjournal-core.la
> libsystemd-journal-internal.la
> libmachine-core.la
> libnetworkd-core.la
> liblogind-core.la



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] why are the systemd binaries so huge and can we do something about that?

[Michael Biebl]

2016-05-17 10:36 GMT+02:00 Lennart Poettering :
> On Mon, 16.05.16 04:24, Michael Biebl (mbi...@gmail.com) wrote:
>
>> Hi,
>
>> Any ideas, why simple tools like loginctl, busctl, hostnamectl require 300K+ 
>> ?
>> What's up with systemd-analyze?
>
> it embedds much of PID1's logic actually, in order to do unit file
> checking.
>
>> Could we move more common functionality into a shared, private library
>> to counter the constant growth?
>
> This has been discussed, and yeah, this should be a good thing to
> do. It's just a matter of doing it. A shared, but explicitly private
> library would be good. I figure it should be built from the stuff in
> src/shared and src/basic. This would mean it won't help in the
> systemd-analyze in case, but I think it's OK, given that that's a
> debugging tool.

Looks like this is not quite that simple. I fiddled with this for a
bit without any success.
We have quite a bit of noinst libs atm [1].
Would you turn all those into pkglib_LTLIBRARIES?
Merge them into a single lib (or maybe two: libudev-internal and
libsystemd-internal?)

[1]
libbasic.la
libshared.la
libfirewall.la
libcore.la
libsystemd-internal.la
libsystemd-network.la
libudev-internal.la
libudev-core.la
libjournal-core.la
libsystemd-journal-internal.la
libmachine-core.la
libnetworkd-core.la
liblogind-core.la

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] why are the systemd binaries so huge and can we do something about that?

[Andrei Borzenkov]

On Mon, May 16, 2016 at 12:06 PM, Martin Pitt  wrote:
> Michael Biebl [2016-05-16  4:24 +0200]:
>> Any ideas, why simple tools like loginctl, busctl, hostnamectl require 300K+ 
>> ?
>> Could we move more common functionality into a shared, private library
>> to counter the constant growth?
>
> Building src/shared/ into a private libsystemd-internal.so (which
> doesn't have a SONAME and shipped development headers, so that we
> continue to be able to change the API freely) should help a great deal
> there.

Well, with static library each (small) binary only picks what it
needs. With common shared library everything must be always present
even if you need just a handful of small binaries. So it really needs
some real life comparison in typical installations.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] why are the systemd binaries so huge and can we do something about that?

[Lennart Poettering]

On Mon, 16.05.16 04:24, Michael Biebl (mbi...@gmail.com) wrote:

> Hi,

> Any ideas, why simple tools like loginctl, busctl, hostnamectl require 300K+ ?
> What's up with systemd-analyze?

it embedds much of PID1's logic actually, in order to do unit file
checking.

> Could we move more common functionality into a shared, private library
> to counter the constant growth?

This has been discussed, and yeah, this should be a good thing to
do. It's just a matter of doing it. A shared, but explicitly private
library would be good. I figure it should be built from the stuff in
src/shared and src/basic. This would mean it won't help in the
systemd-analyze in case, but I think it's OK, given that that's a
debugging tool.

If anyone wants to make the necessary changes to makefile.am I'd be
happy to merge this.

(I figure either by including a version nr in the .so filename, or by
using symbol versioning, we really should make sure that the .so is
bumped on each release and we won't end up with new binaries
accidentally linking against older .so versions or vice versa.)

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] why are the systemd binaries so huge and can we do something about that?

[Umut Tezduyar Lindskog]

On Mon, May 16, 2016 at 11:06 AM, Martin Pitt  wrote:
> Michael Biebl [2016-05-16  4:24 +0200]:
>> Any ideas, why simple tools like loginctl, busctl, hostnamectl require 300K+ 
>> ?
>> Could we move more common functionality into a shared, private library
>> to counter the constant growth?
>
> Building src/shared/ into a private libsystemd-internal.so (which
> doesn't have a SONAME and shipped development headers, so that we
> continue to be able to change the API freely) should help a great deal
> there. Is that something that would be accepted upstream?
Similar discussion:
https://lists.freedesktop.org/archives/systemd-devel/2016-February/035918.html
>
> I wouldn't like to split out things like systemd-analyze just because
> of being a big binary. It's useful for all sorts of things even on a
> non-developer machine: temporarily raise log levels, check
> admin-provided units, and check why your machine takes too much time
> to boot, etc.
>
> Thanks,
>
> Martin
>
> --
> Martin Pitt| http://www.piware.de
> Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] why are the systemd binaries so huge and can we do something about that?

[Reindl Harald]

Am 16.05.2016 um 14:18 schrieb Michael Biebl:

2016-05-16 6:15 GMT+02:00 Auke Kok :

On Mon, May 16, 2016 at 04:24:25AM +0200, Michael Biebl wrote:

1,5M usr/bin/systemd-analyze

What's up with systemd-analyze?


It shouldn't be part of a base package, it's not even a diagnostic tool, more
like a performance measurement type of thing.

I don't think size is of a concern for it.


I do think size is of concern (even today with TB size disks), think
of containers or small/embedded systems.
See the recent developments regarding docker and alpine.


+1

it applies also to virtualization where it makes a difference on *very 
expensive* redundant strorage if every software left and right wastes 
1,2 or more MB of diskspace and you need more reserved space for updates 
and the rest of the system



Atm we have those three options:
1/ don't enable a feature to keep the footprint down
2/ enable the feature but split it into a separate package → risk of
balkanizing across distros
3/ enable the feature but ship it in the main package → accept the
constant increase in footprint


or do what every other software-project does: use shared libraries below 
/usr/libexec



As for some background: we recently got a recent in Debian to enable
and ship the systemd-sysusers binary [1] as this is apparently
required by rkt now. We don't make use of systemd-sysusers in Debian,
so this would mean an additional 300K on every installation which is
wasted for the majority of users. The alternative is to split it off,
which is not too compelling either.
Question is, why systemd-sysusers is such a large binary in the first
place for such trivial functionality. And maybe we can address that.

Regards,
Michael

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=823322


on Fedora 23 systemd has 26 M disk space

frankly i have systems with 650 MB on the rootfs and so systemd alone 
has 4% of the complete virtual machine




signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] why are the systemd binaries so huge and can we do something about that?

[Michael Biebl]

2016-05-16 6:15 GMT+02:00 Auke Kok :
> On Mon, May 16, 2016 at 04:24:25AM +0200, Michael Biebl wrote:
>> 1,5M usr/bin/systemd-analyze
>>
>> What's up with systemd-analyze?
>
> It shouldn't be part of a base package, it's not even a diagnostic tool, more
> like a performance measurement type of thing.
>
> I don't think size is of a concern for it.

I do think size is of concern (even today with TB size disks), think
of containers or small/embedded systems.
See the recent developments regarding docker and alpine.

Atm we have those three options:
1/ don't enable a feature to keep the footprint down
2/ enable the feature but split it into a separate package → risk of
balkanizing across distros
3/ enable the feature but ship it in the main package → accept the
constant increase in footprint

As for some background: we recently got a recent in Debian to enable
and ship the systemd-sysusers binary [1] as this is apparently
required by rkt now. We don't make use of systemd-sysusers in Debian,
so this would mean an additional 300K on every installation which is
wasted for the majority of users. The alternative is to split it off,
which is not too compelling either.
Question is, why systemd-sysusers is such a large binary in the first
place for such trivial functionality. And maybe we can address that.

Regards,
Michael

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=823322


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] why are the systemd binaries so huge and can we do something about that?

[Martin Pitt]

Michael Biebl [2016-05-16  4:24 +0200]:
> Any ideas, why simple tools like loginctl, busctl, hostnamectl require 300K+ ?
> Could we move more common functionality into a shared, private library
> to counter the constant growth?

Building src/shared/ into a private libsystemd-internal.so (which
doesn't have a SONAME and shipped development headers, so that we
continue to be able to change the API freely) should help a great deal
there. Is that something that would be accepted upstream?

I wouldn't like to split out things like systemd-analyze just because
of being a big binary. It's useful for all sorts of things even on a
non-developer machine: temporarily raise log levels, check
admin-provided units, and check why your machine takes too much time
to boot, etc.

Thanks,

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] why are the systemd binaries so huge and can we do something about that?

[Auke Kok]

On Mon, May 16, 2016 at 04:24:25AM +0200, Michael Biebl wrote:
> 1,5M usr/bin/systemd-analyze
> 
> What's up with systemd-analyze?

It shouldn't be part of a base package, it's not even a diagnostic tool, more
like a performance measurement type of thing.

I don't think size is of a concern for it.

Auke

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] why are the systemd binaries so huge and can we do something about that?

[Michael Biebl]

Hi,

systemd has a tendency to grow in size with each new release (and I
mean installed Mb on disk here).

Looking at the size of a couple of binaries, I'm really suprised they
are so huge:



36K bin/systemd-notify
36K usr/bin/systemd-cat
36K usr/bin/systemd-detect-virt
40K bin/systemd-escape
44K usr/bin/systemd-path
48K bin/systemd-machine-id-setup
52K bin/systemd-ask-password
64K bin/systemd-hwdb
64K usr/bin/systemd-delta
68K bin/systemd-tty-ask-password-agent
76K usr/bin/bootctl
132K bin/systemd-tmpfiles
140K usr/bin/coredumpctl
276K bin/systemd-inhibit
288K usr/bin/hostnamectl
292K usr/bin/systemd-cgls
296K usr/bin/localectl
296K usr/bin/timedatectl
304K usr/bin/systemd-cgtop
328K usr/bin/systemd-resolve
344K usr/bin/systemd-stdio-bridge
364K usr/bin/busctl
368K usr/bin/systemd-run
436K bin/udevadm
444K bin/loginctl
476K bin/machinectl
488K bin/journalctl
572K usr/bin/systemd-nspawn
648K bin/systemctl
656K bin/networkctl
1,5M usr/bin/systemd-analyze

Any ideas, why simple tools like loginctl, busctl, hostnamectl require 300K+ ?
What's up with systemd-analyze?

Could we move more common functionality into a shared, private library
to counter the constant growth?

I'm really concerned that a simple "make install" here takes up more
then 30M here.

Regards,
Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel