Il 07/08/2012 14:47, Sylvain Alain ha scritto:
Hi everyone, for a couple of months now, I see on the list some of
activities about OpenRC been ported to FreeBSD or OpenRC to Debian and
other stuff related to SystemD.
I have some basic questions about all that :
1. The SystemD and Udev projetcs are merged now, so what is the impact
on the Gentoo on a short term period ?
The answer is in the hand of others, I sincerely hope someone will fork
2. I saw on some lists that Gnome/Kde and Xfce plan to use some
SystemD API, so does it means that we will need to install SystemD
aside of OpenRC ?
It's not possible at the moment. systemd break non-systemd setups.
3. In a long term vision, can OpenRC still exist on a Gentoo
box(OpenRC might be able to boot the box then give the control to
SystemD/Udev for the rest of the boot process) or we will need to
migrate to SystemD to be able to use Gnome/Kde or Xfce ?
PID 1 has some own properties, but systemd can work at user privileges,
maybe
4. Finally, is there any reason why Gnome/Kde/Xfce wants to add deps
related to SystemD ? I don't understand why these desktops want to
depend on a specific Sysint....
Because starting daemons it's much more error prone than everyone
thinks, at least everyone which didn't become involved in coding for it.
And now my personal rant with some considerations, from memory, may be
not totally accurate.
Tried systemd (SD from now) the other day, as everyone knows it need to
rebuild some part of the system with the "systemd" use flag.
These things broke when not started by SD, for example pulseaudio, had
problems also with auto-mount possibly more not even noticed.
This box has 3 disk:
sda) ssd on sda for gentoo whole disk (not partitioned)
sd{b,c}) /home /srv /boot md raid 1
First problem udev/SD has is that it can't see all the file system
labels, for some reason it only see sda and sdb so it's able to partly
proceed in the boot sequence, mount / (root) but can't mount anything else.
After putting in fstab the real /dev paths (something really old siecle)
manually mount them with systemctl --ignore-deps (the name of the option
is different please bear with me) works but the dependancies are not
satisfied, for two reasons:
a) SD does not re-calculate it's deptree/services when exiting from
rescue shell, it still try to start the "virtual" services as fstab
would have never modified, a reboot is needed
b) since it does not work even after reboot, there must be something
else, but what? this bring us to the point
SD has mainly two things to debug boot `systemctl dump` and
`systemd-journal` but the very much magnified advantages of the binary
log^W journal are totally invisible in this case because it's
difficult^W nearly impossible even to understand WHAT failed to start,
not to mention WHY
the magnificient binary log^W^W journal is kept on tmpfs (in ram) so
it's not even available at boot in different situation.
every try needed many minutes because SD wait for a long timeout before
going to the rescue shell, gave up after few hours of try, upgrading
Vista SP0 to current needed less reboot and time.
But this has been beneficial because I've now realized few important
things that will be probably never disappear from SD and will be there
forever, things that make me think this stuff is really dangerous.
List of problems that will _never_ be fixed
- SD does not see anything else than systemd for boot.
Interaction with SD from a livecd, is difficult, almost all tools don't
work because SD is not running.
transported on remote server administration this is a *nightmare*,
various provider offer livecd like system which don't offer SD.
so no easy migration, no easy first install, every failure is
definitive, a no go
- the journal will never become simpler, can only grow, debugging things
in the shell will be nearly impossible for excess of data (and lack of
useful one if it continue this way)
- virtual/autogenerated services are and will be difficult to cope with,
impossible to disable
- every change in the early boot procedure will require reboot
- which sum to: SD will work until it work, when something does not will
be a royal pain to solve _and_ nothing else other than SD will be
available to alleviate the pain
difficult to accept for the desktop, impossible for the server.
written by someone which like _some_ of the SD stuff.
