On Wed, Jul 13, 2016 at 03:54:46PM -0700, Rick Moen wrote:

[cut]

>
> > 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.

Look Rick, Devuan is exactly trying to do this, in a consistent and
comprehensive way, well before it will be too late.

[cut]

>
> > 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.

I think I know very well what you said, since I believe I can
understand English a little :) The conclusion seemed to be that since
pinning worked for your use case, there was no reason to fork Debian
and start Devuan. The latter one is either a logical fallacy on your
side, or my misunderstanding of what you have written. I wouldn't be
bothered that much in either case.

The bottom line is: what you think works for you might not work for
others :)

[cut]

>
> 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.
>

Well, you know better than me by now that each user tends to put
himself at the centre of the world, and is normally biased in thinking
that his or her use case is so common that there is no reason why
people should need anything else. Reality is a bit more complicated
than that, and ways more colorful :)

[cut]

>
> 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.

There will probably come a day in which the amount of work you need to
do in order to work around blockheaded distro policies will be so
large that you would be better off using some other distro, if you can
find any other distro around that does not have the same problem. Or
you will be forced to make your own distro (which is something that
almost anybody with a basic understanding of Linux should be capable
of doing).

>
> 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 call it duct tape, because if I choose a distribution like Debian
Jessie, which has 42000 packages available, and then I end up being
able to use roughly 60% or 70% of them if I don't want systemd around,
then what I need is another distribution, and if it is not just know,
it will be the case in the near future.

Debian used to be one of the few distributions which enforced
basically one policy: the package management system and the dependency
ecosystem. Apart from that, you could have a countable (meaning,
potentially infinite) set of different incarnations of Debian, one for
each of the countable operational policies needed by its users. Debian
was providing the tools, you were implementing your own policy, which
is a very successful common practice in the unix world.

Now things are markedly different, and if I want to use Debian "my
way", I have to circumvent several additional policies (all necessary
to accommodate the needs of the same group of users, to which I don't
belong) that were not there before.

I might decide to carry on for a bit, at least as long as the work I
need to do in order to bend those policies to *my* policies is not
massive. Or I might decide to use another distro. Or to modify Debian
in order to remove what I personally believe is *odd*. Or to create
another distro. Or to move to another unix flavour out there
altogether.

Free software allows us to explore different routes, and there is no
"right" one, in principle. The one which will survive and produce
off-springs will be the correct one. The others will just be
forgotten, sooner or later, and disappear. And yes, it will not be the
end of the world.


> > 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.

You know better than me that the main reason why you and me are
discussing this matter is that systemd is trying very hard to impose
"one-and-only-one" policy to the whole Linux ecosystem. And they are
currently doing very well at that. If it were just another set of
mechanisms, nobody would have cared, and this is the reason why most
people seem to not care: they just perceive systemd-stuff as a
"tool". Let's try different ways to contain this problem, since it is
a very serious problem.

The rest is mostly rhetoric that we auld aunties like to sprinkle over
long emails, for our own pleasure :)

HND

KatolaZ

-- 
[ ~.,_  Enzo Nicosia aka KatolaZ - GLUGCT -- Freaknet Medialab  ]  
[     "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
[       @)   http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
[     @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ] 
[ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]