Re: End of hypocrisy, beginning of reason
On Tuesday, August 5, 2014 10:10:02 PM UTC+5:30, Steve Litt wrote:
> On Tue, 5 Aug 2014 09:17:15 -0700
> Don Armstrong wrote:
> > On Tue, 05 Aug 2014, Slavko wrote:
> > > To be precise, i often read about these things: monolitic, binary
> > > files and boot speed. I don't like first two and i am not interested
> > > in latest.
> > These are just accessible reasons. The main reason that I personally
> > voted for systemd over sysv is because systemd (and upstart) provide
> > correct boot sequencing in complex boot situations.
> > For example, if you're using iscsi, and need to start a daemon after
> > the network is up, iscsi is connected, lvm has resynced, and the
> > appropriate filesystems are mounted, this is trivial using systemd or
> > upstart, but very difficult using sysv.[1]
> > The other reason is we also get rid of thousands of lines of
> > difficult-to-maintain boilerplate in init scripts.
> > While sysv may be easier to debug in simple systems, there's a reason
> > why none of the CTTE members (myself included) voted for it.
> > 1: Not impossible, but you basically end up replicating a dependency
> > boot system in shell, and necessarily introduce brittleness and
> > delays.
> Cool! Finally someone who knows it and is on the ground floor. I have
> some questions...
>
> What other tips would you have for those of us who want to, to the
> extent possible, keep systemd as nothing more than the first program to
> be booted, and want to reduce as much as possible what other programs
> need to know about systemd and what systemd needs to know about the
> programs I run?
I have a basic question: I want to migrate to systemd [reasons below]
However...
1. I see on this list itself evidence of breakage
2. Ive experienced some myself and I could only guess that it was a
systemd issue until it was pointed out by Michael that it is probably
a mismatch between sysv and systemd. However given that people are
getting totally unbootable systems, I's just being a bit careful.
What I want is a process where something can be tried out (gingerly)
and reversed or fixed-in-concrete depending on results.
Ive seen some things about trying out by giving systemd at the grub line.
Im already seeing systemd in mount:
systemd on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,name=systemd)
However aptitude dist-upgrade shows me:
The following packages will be REMOVED:
graphviz{a} rsyslog{a} sysvinit-core{a}
And a 1/2 GB worth of packages to be upgraded including systemd
So I am a bit jittery about going ahead -- removing sysvinit-core seems a hard step to reverse :-)
>From a more theoretical/computer science pov:
Why I (for whatever its worth) think systemd is (could be) a good idea:
Declarative is invariably better than imperative though it can be hard to
get right at first. And systemd tries to be more
declarative than sysv.
Whether it succeeds is a different question ;-)
How to make it succeed (with minimal pain) is what I am asking...
Reply to: