On 2 July 2011 01:03, Greg KH <gregkh@suse.de> wrote:
On Sat, Jul 02, 2011 at 01:11:45AM +0200, Eberhard Moenkeberg wrote:
Hi,
On Fri, 1 Jul 2011, Linda Walsh wrote:
Linda Walsh wrote:
Can I ask a question about this....and maybe someone could explain why this would be 'infeasible'
Why not have 'init' start things as it does now up through the 'boot' scripts', then turn starting 'services' over to the task of 'systemd' when hardware to serve all the user -level application programs that
I really like Linda's idea of a "hybrid approach".
It would avoid the initial (huge!) disturbance systemd would serve us, and allow a smooth way to a "total" conversion when systemd really is ready, step-by-step.
No, systemd is designed to be init, and expects to run as init, so doing something like what you are mentioning would actually be more work than just doing the systemd integration properly.
And again, the remaining systemd tasks have all been described quite well, and you can test today, in Factory or Tumbleweed if you want to. Please let people know what is not working properly for you so it gets fixed in time for 12.1.
Furthermore it IS NOT systemd that requires /usr to be in /, but the application hooks for things like Bluetooth into udev! systemd just prints a warning about running a flakey unsupported configuration. It is the initrd responsibile for mounting / and populating /dev from a minimal "memory" Linux environment, that would need to be changed to know how to mount /usr. What ppl really want is not startup to be delayed until all the local filesystems are mounted, but to have some path resolution block when they hit scheduled mount points that haven't been completed (started even) yet so it's much finer grained, effectively like network automount but on any mount point. But again, even with that kernel support udev would have to be altered to expect rules to block, and a list of future mount points would have to be loaded to block on them. In old days, it would take ages for an array of disks to spin up, then you had some long fsck(8) checks on some Archive, which kept the whole machine out of service, when it COULD already be serving home directories & routing email say. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org