Quoting KatolaZ (katolaz@???):

> Wait :) First of all, I might have been unclear in the previous email,
> but I really appreciate your work, and that of others who are making
> an effort to contain systemd. So there is no reason to start a fight:
> that's not my intention at all, and would be counterproductive and
> useless beyound measure :)

Sorry about any misunderstanding.

> I might be mistaken on this, but my understanding is that already in
> the current Jessie if you don't have systemd and polkit installed you
> can't shutdown your system from GNOME, and from other WMs and DMs, for
> that matter.

That has not been my experience with Window Maker.

I've heard of some DE glue not working if you lack PolKit and/or upower
_by default_, but can't remember details. It was something like XFCE4's
shutdown graphical controls didn't work until you retofit optional
package blahblahblah.

And my recollection is that you can find the 'retrofit optional package
blahblahblah' tip in every case I've observed that to be findable in
five minutes of Web-searching.

Personally, if a DE or WM gave me more than five minutes of trouble in
this area, I'd just fall back on the workaround that's sufficed since
dinosaur days:

$ su -
$ shutdown -h now


> I don't use GNOME, and I never shutdown or reboot my machines unless a
> cataclysm has struck, so I could safely ignore the problem, but I know
> that pinning systemd does not solve it. It just "contains" the
> avalanche, in some cases, and postpones the search for a solution to
> an undetermined point in the future, but does not *solve* the problem.

Everyone keeps telling me that the Poettering Horsemen of the Apocalpse
are producing thundering hoofbeats just around the corner, and they keep
not coming around the corner. Some day, this could change, but there's
sure a long history of it not doing so, and (in my experience)
commenters keep ignoring modest fixes.


> Good. Nice. Perfect. I care about a solution that goes beyond my needs
> of today, while that is not your first priority. I think we can safely
> disagree on this point and continue :)

Works for me.

I might care about 'a viable long-term solution for the Linux
community'. I might care deeply.

I'm an old-school Linux system administrator who long ago got wary of
sweeping rhetorical claims, and prefers to discuss specific things where
possible, and to be careful about definitions/meanings when not.


> I am pretty sure I have never raised any critique to your work. I have
> just stressed that I *believe* that, given the current attitude of
> systemd & co., that consists into eating as much as they can of almost
> anything in the low-level userspace, breaking things in the process
> without saying "sorry", there is probably not much time left until
> everything down there will depend on systemd.

I am not at all convinced of this.

However, I'm quite certain that such eventualities would immediately
inspire creation and publication of even more alternate packagings and
repos of same, to sidestep that and fix that (hypothetical) step.

I am, speaking for myself, an example of a Debian-using system
administrator who became aware that, through laziness and inattention,
I'd stood by and let some pieces of questionable software enter my
systems, starting with udev. I'd already started to (belatedly)
question the necessity, and to ensure that upower, udisks2, PolKit,
packagekit, and the rest of the Freedesktop.org CADT bugpile did not get
pulled into my systems via dependency chains. I have tended to mostly
stop with Works for Me[tm] corrective measures. If there were a bigger
intrusion problem, I would take stronger measures. (My page hints at
the general shape those would probably take.)

> Hence, pinning is not, IMHO, a viable long-term solution.

This does not follow logically from your premises. However, {sigh} also
I did not _say_ package-pinning is a viable long-term solution (to
anything in particular).

What I said was 'Hey, I tried, this, it works for these [cited]
use-cases.' And then I said 'Third-party repos with package preferences
are an already-proven way to perpetuate a Debian-variant community,
imposing an external policy on it. I see no reason this could not
be used with a no-systemd policy.'

And I said a lot more, such as (when challeged by Mr. Steve Litt about
my opinion that Devuan was an overreaction) outlining general methods of
maintaining Debian-variant communities that are already proven and in
use.

> See above. I genuinely appreciate your effort, which is scientific and
> sound, and I know that *so far* it is still possible to find
> appropriate workarounds around systemd, remaining in Debian and
> accepting a few compromises.

I just don't see those as compromises.

There's not a single package in the list of problem packages on
http://linuxmafia.com/faq/Debian/openrc-conversion.html that I care
about.

NetworkManager? GNOME crud.

gdm3? GNOME crud.

nautilus-dropbox? GNOME crud.

apper? GNOME crud.

daisy-player? I don't use text-to-speech, and if I did and wanted that
package, I'd use dpkg-buildpackage to recompile and rebuild the package
locally without the dumb GNOME build dependency.

The only package my survey found that gave me pause was package 'hplip'
-- until I found in a couple of minutes' reading that it's a bloated
metapackage with GNOME crud, and that what you actually want is packages
printer-driver-hpcups and printer-driver-hpijs. So, I made a point of
documenting that in particular.

'Avoid GNOME crud' is in fact good overall advice. ;->

I specifically say I do _not_ speak for all use-cases. However, my page
does cover an enormous range of use-cases. Unless it has errors -- and
I keep asking people what 'important' packages I'm missing and (e.g.)
what 'compromises' there are, and I hear nothing back except lazy
rhetoric.


> But I know that two years ago we had a very nice brand-new toy, which
> was working perfectly, and for which such workarounds were not needed.

{shrug} To a first approximation, I care only about working systems for
my use-cases. Which doesn't include NetworkManager or the
most-bloated DEs.


> You are optimistic, and think that a small amount of duct tape will be
> enough to fix the toy, now and in the future.

I wouldn't say optimistic. I'd say process-oriented and skeptical,
i.e., I'm a senior system administrator.

> My pessimism forces me to believe that more and more duct tape will be
> needed, to the point that the mended toy will become a basically
> useless Frankestein.

Well, I've abandoned even entire *ixes _before_. The sky didn't fall
when I blew away AT&T System V release 3.21 and Novell Unixware 2.0
(IIRC) to migrate to 386BSD, it didn't fall when I blew that away to
replace it in 1993 with a Linux system compiled up from H. J. Liu's
boot/root floppy Linux images, it didn't fall when I replaced that with
Slackware, it didn't fall when I replaced that with Red Hat Linux, it
didn't fall when I replaced that with Stampede Linux, it didn't fall
when I replaced that with Debian-stable, and it didn't fall when I
replaced that with Debian-unstable/testing.

I greatly doubt that a bunch of Freedesktop.org desktop-computing
weenies and GNOME freaks are much of a threat to my computing stability,
maintainability, and security, but I have a great deal of experience
working around blockheaded distro policies, and tools I can sharpen to
do as much more of that as circumstances merit.

You call it 'duct tape'. I call it local implementation of policy.
This is, frankly, _exactly_ what all of the professional field
Operations concerns. Local packages as required, local configuration in
version control, applied preferably by configuration management software
(chef, puppet, ansible, salt, cfengine -- pick your poison).

> I am firmly convinced that both pinning and forking experiments should
> continue anyway. At least, if one approach fails at some point, we
> still have the other one available as a plan B :)

Agreed. _And_ other measures to locally impose policy (many detailed on
my page), short of forking entire distributions. I keep having to
mention that, for some reason.