On 05/25/2012 03:52 PM, Bruce Dubbs wrote:
>> $ systemd-analyze
>> Startup finished in 1686ms (kernel) + 7995ms (userspace) = 9682ms
>
> It's not clear what that does. From dmesg, it looks like the kernel is
> till running at 6.7 seconds. It will take a little longer for the
> kernel to load all those modules.
>
> I don't understand where systemd gets it's numbers. It
>
[ 1.176174] Switching to clocksource tsc
[ 1.374790] systemd[1]: RTC configured in localtime, applying delta
of 120 minutes to system time.
[ 2.487258] udevd[55]: starting version 183
So, basically kernel finishes loading of builtin stuff at 1.176 seconds
and then systemd starts and pulls in udev. That's where it gets that
value from. Others are just modules, and they are running paralely with
other services. As for other messages, it's just usb subsystem which
turns on and off my mouse for some reason.
>
> cgroups should be optional. Imposing complexity on simple problems is
> not letting the user decide.
>
No, it is listed in README as requirement. Also it is not systemd's
fault that kernel exposes cgroups like that.
From README:
REQUIREMENTS:
Linux kernel >= 2.6.39
with devtmpfs
with cgroups (but it's OK to disable all controllers)
optional but strongly recommended: autofs4, ipv6
dbus >= 1.4.0
libcap
PAM >= 1.1.2 (optional)
libcryptsetup (optional)
libaudit (optional)
libselinux (optional)
tcpwrappers (optional)
>> securityfs seems to be hardcoded into systemd binary. Others are cgroups
>> which expose like that. Also, /tmp can be set not to use tmpfs if desired.
>
> Another case of taking away user choice.
>
I agree on this one. It was optional untill 183 I think. But that one is
disabled in kernel by default, so it won't get mounted unless you enable
it in the kernel.
>> So, is LFS still going to avoid systemd? I said on trac that it is not
>> possible to install just udev from systemd tarball.
>
> I've asked on the hotplug list, but I havn't received a response.
>
Well, I have to disappoint you. Systemd announce mail arrived today and
I'll just post some highlights from Change Log:
* udev: all udev sources are merged into the systemd source tree now.
All future udev development will happen in the systemd tree. It
is still fully supported to use the udev daemon and tools without
systemd running, like in initramfs or other init systems. Building
udev though, will require the *build* of the systemd tree, but
udev can be properly *run* without systemd.
* udev: the daemon binary is called systemd-udevd now and installed
in /usr/lib/systemd/. Standalone builds or non-systemd systems need
to adapt to that, create symlink, or rename the binary after building
it.
>
> If you want to build a simple web server with no xorg, why would we need
> dbus? Another case of imposing a lack of choice.
>
DBus is really no big problem. You can't avoid dependencies just like
that. I don't think it would be problematic for anyone using server
since it does not use nearly anything when it comes to resources.
Also, if you think of a *simple* server, you can ditch udev and create
static nodes. Again, LFS gives user a choice. It is up to user to decide
what they need and what they don't need.
Today's hardware is not very limited, so I think 2 or 3 libraries
compiled into something, or service or two more running won't make it
collapse.
But yeah, there are always minimalists that will get in someone's way of
accomplishing something. We argued on this once already, so no arguments
this time please.
I just want to make clear one thing that will most people say
Note: I don't know how big is something. Just trying to make some analogy.
" Systemd is big. How can someone compare 100 000 lines of systemd code
with 1000 lines of init code. Also, Bootscripts are simple, they just
require 5 or 10 lines. "
This one is not true in many ways. Systemd will act as many programs as
it's possible.
Bootscripts functions use at least 5 or so programs including grep, awk,
bash itself and so on. So you can count 10 000 more lines to the 1000
lines of init program.
Also, it interfaces directly with libkmod without any need for modprobe
tools. Count out 1000 lines more to that.
It uses builtin fsck functions that only interface with fsck.fstype, so
no need for big initscript for that.
It uses system calls for setting hostname, so you can count several
lines of hostname program to the number above.
The point of all this is: Yes, it is bigger ... But it is far more
powerfull. And yes, it does not give the user view of what it's doing.
You can count out at least 20 000 of lines for userspace programs like
analyzer, graphs and systemctl which is really nice tool, which can
enable/disable services (analog of initd-tools for sysvinit scripts),
which can display which services are running, status of the service,
when it was started and such.
There is also a journal which can act as system log and logind which is
an login daemon which aims to replace consolekit. So, not really part of
init system. Count out at least 10 000 lines more of the code from above.
And of course, systemd has full compatibility with sysvinit scripts as
long as they have LSB headers. It can manage them very well.
So no offense, I was just trying to explain that systemd is not that
bigger, but it does include some features that someone might not want,
need or like.
>> Also, if intended to use systemd-logind as consolekit replacement,
>> linux-pam is necesary for pam_systemd.so.
>
> We use the login from shadow.
>
Just listing optional deps and telling what is their use.
Also, dbus-python is required at runtime for systemd-analyze.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
