Re: Tentative summary of the amendments
On Sat, Oct 25, 2014 at 12:51:04AM +0300, Aigars Mahinovs wrote:
> On 24 October 2014 23:16, <josh@joshtriplett.org> wrote:
> > I'd personally be interested in your non-devil's-advocate reasons for caring, because
> > those seem likely to be solvable.
>
> I, personally, love the init part of systemd - the part that starts
> services (either on startup or on events).
>
> >> and there is no
> >> need to hardlock them into the init system too.
> >
> > I really wish you'd stop asserting this. You, and others, would
> > *prefer* that they're not part of the init system. That opinion (and it
> > is an opinion) on design and architecture is not universal, and there
> > are quite a few documented and frequently reiterated reasons to
> > integrate such features into an init system.
>
> Let me rephrase that - my opinion is that it would have been almost as
> easy to design and implement the IPC parts of systemd in such a way
> that they could be used independently from the init system part. In a
> way where users could mix and match the parts that they want to use in
> a particular system. I know of ability to compile out some parts, as
> far as I understand that still does not allow to, for example, run
> logind from a bash shell. And, from what I hear, it is highly unlikely
> that patches to that effect would be accepted upstream.
Have you looked at the IPC interfaces of systemd, such as
org.freedesktop.systemd1? Take a look at
http://www.freedesktop.org/wiki/Software/systemd/dbus/ , and reconsider
that opinion on ease of separate implementation. The primary .Manager
interface provides detailed access to and control of units, jobs, system
state, systemwide environment, and transient unit launching; none of
that makes any sense to handle outside of systemd. The same goes for
all of the other DBus interfaces, such as the scope/slice/cgroup/etc
interfaces used to dynamically set up and manage process groups at
runtime; on a systemd system, not one of those interfaces makes sense to
implement outside of systemd, because they're specifically about
constructing, controlling, and monitoring groups of processes, which on
a systemd system is systemd's job.
To use logind as an example service, because it's both the most widely
desired service *and* one of those most closely tied to systemd: logind
is specifically designed around cgroups and process/session supervision,
as an inherent part of handling seats, sessions, and user permissions.
Thus, logind uses scopes, slices, and various other interfaces, via the
systemd dbus interfaces.
systemd-shim implements versions of the interfaces needed to support
systemd services outside of systemd. Some of those interfaces are
stubs, such as mocked-up unit properties for specific units that would
exist on a systemd system, and others are fairly simple
(shutdown/hibernate). However, the scope/slice/etc handling is
non-trivial, and built upon cgmanager. I certainly would not put down
the work of the systemd-shim developers and maintainers by suggesting
that doing so was *easy* to implement outside of systemd; it's hard
enough to implement *inside* of systemd.
(The paragraph above should be taken with a grain of salt, as I'm not an
expert on the internals of systemd-shim.)
In any case, I don't think it's reasonable to take the existence of
systemd-shim as an argument that the interface could have been designed
for use independently of the init system, at least not with the same
capabilities. systemd-shim doesn't actually provide most of systemd's
functionality; it just provides a shim that lets logind run.
As an analogous situation (derived from the branch of this thread that's
discussing the analogy to kernels and architectures): I don't think it's
reasonable to take the existence of the Linux IIO ("Industrial I/O") and
FUSE ("Filesystem in Userspace") frameworks as arguments that the
majority of device or filesystem drivers should be written outside the
kernel.
> > On the contrary, you gain a great deal of flexibility, without having to
> > write any extra support for it. Want to run another instance on another
> > port? Add another .socket unit. And note that you can do so in a
> > systemd --user instance if you want, or ephemerally via systemd-run or
> > systemd-activate. Easy to start a debug version that way too.
>
> We need to do a lot of work on updating Debian Policy and Debian
> Reference.
Working on that, along with many other people. :)
> I am learning new features of systemd with every week of
> these discussions.
:)
That's one of the reasons I prefer to have discussions about more
concrete questions and concerns, rather than abstract, theoretical, or
hypothetical issues. Concrete questions and concerns have concrete
answers.
> I still don't like the tightly integrated design,
> but that in itself is just an irrelelvant opinion.
There are people who still dislike Linux for not being a microkernel. :)
And I wouldn't call your opinion *irrelevant*. It's a valid opinion,
with some arguments in its favor; it happens to disagree with the
direction and architecture of several widely used pieces of software,
but that doesn't make your opinion *irrelevant*, just difficult to get
support for.
> >> Applications have never
> >> been calling init system before. Try the same assumption with: bash,
> >> Metacity, gnome-shell. "When you application is started, it might be
> >> started by gnome-shell, in that case you may give gnome-shell an
> >> indication about your startup animation, but you may be started by
> >> something else, in that case you should still start, but it is fine
> >> not to provide the correct startup animation."
> >
> > Talking about "startup animation" dismisses features and integration as
> > trivial frivolities. Since you mentioned gnome-shell and metacity,
> > let's talk about an analogous situation to the systemd case. Formerly,
> > in GNOME 2, you could run a "panel applet" on top of gnome-panel, and
> > run gnome-panel within any desktop environment and window manager you
> > liked. Neither gnome-panel nor those applets exist in GNOME 3
>
> Even though those were clearly understood to be plugins of the panel
> and not actual applications, there was quite passionate discussion
> about both porting them to Gnome 3 and about making a freedesktop.org
> common ground specification. Basically system notification area came
> out of that as far as I rememeber.
I'm aware. The situation still stands, though, and the existence of
ways to write more-portable, less-capable extensions (such as tray icons
or notifications) does not negate the substantial ecosystem of
gnome-shell-specific extensions. The same holds for init systems. Yet
I don't see anyone clamoring to *prohibit* dependencies on specific
desktop environments. Nor do I think an attempt to do so would be any
more productive or effective.
> > You're also implying that, out of a clear blue sky, the TC would declare
> > a new default, as though they weren't asked specifically to decide an
> > already contentious issue caused by a huge number of people *wanting* to
> > support a new init system and being FUDded away from doing so.
>
> Actually I am suggesting that TC would make a trivial decision on what
> is to be the *default* architecture, while other people would choose
> to understand that this decision means that all other architectures no
> longer matter.
I think you've reversed cause and effect. There are a large number of
people pushing to use systemd, and *because* of that systemd became the
new default, as well as separately growing a set of software that
depends on it. The TC's decision to make systemd the default is not the
reason why people want to build software that uses systemd features.
> > Finally, you're suggesting that code already exists that would be
> > "cleaned up" and removed, and assuming that's the only reason to limit
> > architecture (or init system) support. The common case here, however,
> > would be *new* code to implement some new feature, depending on some new
> > support provided by (for instance) a new service.
>
> That is exactly what I am suggesting - the reason for the clean up
> would be to reduce maintenance burden and add new features by using
> features easily available on the default architecture (both perfectly
> fine reasons), but the side effect is loss of support for other
> architectures (which is no longer considered to be important by the
> upstream or maintainers).
You're still conflating two separate items there, as though the software
would just work on all init systems if only it didn't delete the
pre-existing code to do so. As I said, the common case is either
writing new software and not writing that extra code in the first place,
or adding new functionality to existing software that depends on
functionality or services provided by an init system. In the latter
case, that functionality and those services are *not* trivial to
duplicate.
- Josh Triplett
Reply to: