Re: init system agnosticism [WAS: how to remove libsystemd0 from a live-running debian desktop system]

[Enrico Weigelt, metux IT consult]

On 13.04.2017 11:27, Vincent Danjean wrote:

>   For me, the first argument explain in the first mail is not this one.
> systemd is not portable on lots of system (hurd, kFreeBSD, ...), 

This is just one of many arguments for not making applications
depending on it. (and they shouldn't depend on any other init system
either).

Regarding service status reporting, systemd folks indeed make a good
point. There is some demand for that, and they solved the problem for
their audience (unfortunately only for *their* audience), and moved
one to the next topic. For a prototype that's really fine, but not
for long term maintenance over dozens of different platforms.

Now stating, everybody should just implement their interfaces is just
like asking everybody to implement it in the windows way (NT came up
with it's entirely own service management system, which works quite
well, as long as you're confined within the windows world)

> systemd is not interested in making its code portable, nor to stabilize
> its interfaces so that other system init can easily implement them,

Well, that's their choice, and I respect that. It's just not mine.
I don't wanna be forced into their ways (as I wouldn't ever try to
force them into mine). So, I'm looking for a *generic solution* for the
actual problem, which that functions ins libsystemd aimed to solve,
so applications can just use them, w/o ever having to care which init
system might be installed (or if there even is one at all)

> lots of applications are now using libsystemd to get 'classical' information
> (status, ...) because they do not want to have to deal with several init
> system 

Exactly. They're just looking for some API for that stuff, not caring
what it actually does under the hood. And systemd just happens to
provide one. From the application developer's pov systemd is filling
some gap, and they dont even wanna care about the consequences.

So, it's up to us, to provide a better solution - just telling how bad
systemd is, isn't just enought (from their perspective).

> and porters of platforms not supported by systemd have a really hard
> work to follow systemd developments and patch all things.

Exactly. For some arbitrary application developer (who usually doesn't
even know much about packaging, etc), it's hard to understand the
underlying problem - they just want something they can set their code
ontop (that's also the reason why all these strange proprietary
platforms can even exist). So, it's up to us, who know better, to give
them something they can work with, and that doesn't cause all the
trouble that Lennartware does.

>   From your mail, you seems to deny this issue ("everybody can be pleased
> with systemd" and/or "this is not a general problem, just a problem
> from people that dislike systemd"). For what I see, it seems a problem
> also for people that like systemd but cannot use it on their plate-form
> (Hurd, ...)

Right, it's basicly the same old "shut up and go away" attitude.
Actually, many people already went away, and more will follow.

If it goes on that way, we'll end up w/ an own OS called systemd, which
is as far away from GNU/Linux as Android. Do you folks really want that
or did you just ran out of better ideas ?

>   I'm persuaded that ignoring this issue will lead to an unmaintanable
> Debian distribution on platforms that do not support systemd in the
> middle/long term. But, perhaps, it is what the project wants.

That, in turn, would lead to Debian step by step defeating its own
original goals. I'm pretty sure that it won't take long for lots of
other things (beginning w/ other kernels) are dropped, just because
nobody is willing to keep it compatible w/ systemd.

>   Enrico is proposing something else. I'm not sure if his proposal is
> good and doable (ie with enough support from various parties and
> manpower).

If we get out of the ideologic war (including the upstreams, too),
it wouldn't be such a big deal. A minimal implementation the proposed
library is quite simple and small. We'd just have to touch a bunch of
applications and rewrite a few lines there - and once it works and
included in a major distro, we have good chances for convincing
upstreams to take our patches in. And I'm sure, Devuan folks, which
had been driven out of Debian, will help here, too.

Yes, somebody needs to maintain the systemd-version/branch - but as the
library interface will be stable (it's scope is quite limited, so there
wont be much desire to add anything new). So, we at least have the
overhead of keeping up w/ systemd minimized and centralized in one
small lib. Maybe even someday systemd folks have some moment of insight
and take that part into their hands.


--mtx

Re: init system agnosticism [WAS: how to remove libsystemd0 from a live-running debian desktop system]

[Russ Allbery]

Vincent Danjean  writes:

>   I'm persuaded that ignoring this issue will lead to an unmaintanable
> Debian distribution on plateforms that do not support systemd in the
> middle/long term. But, perhaps, it is what the project wants.
>   Enrico is proposing something else. I'm not sure if his proposal is
> good and doable (ie with enough support from various parties and
> manpower).
>   I'm not pleased at all with arguments to stop this discussion nor
> with arguments that try to deny the issue. I do not know what can
> really be done to solve the issue.

To be clear, I would be very happy to have the above conversation.
Figuring out portability is important to the project, and we should be
constantly looking for good ways to maintain and improve our portability,
particularly given that this was the primary downside of the systemd
decision we took (and we knew that when we took it).

This is an important discussion, and I don't want to shut it down.

What I want to shut down is iteration N of "you all are looking at this
problem in the wrong way and if you would just look at it my way, it will
be immediately obvious that you're wrong."  Or "systemd is obviously not
the correct architecture, so let's get together and design a better one as
a project."  People have been trying both of those approaches continuously
since the original discussion, and, to be quite frank, they no longer fill
me with a desire to collaborate.

Rather the opposite; it's very hard to resist the (I believe incorrect,
but still very human) reaction of "well, I did care about the use cases
systemd doesn't support well, but since everyone who talks about those use
cases seems way more interested in lecturing me and attacking me than
solving technical problems, let me go lower this on my personal priority
list even farther."

I think there's a lot of room here for technical discussions focused on
*specific* technical problems or possible solutions, as opposed to broad,
sweeping generalities about "open standards" (aimed at a fully open-source
project with very comprehensive documentation!) and "actual root
problems" that don't spell out (a) what's wrong with the current state,
(b) how we propose to fix it, and (c) at least some vague start at an
actionable plan to achieve that.  Or that aren't at least *trying* to
spell out those things.

One thing that would help considerably would be to have a clear set of
requirements from the non-Linux ports in what they actually want from the
rest of the archive in this area (assuming they are seeing real
portability problems in the current state).  Specifically, a constructive
list: "please support this," as opposed to "please don't support that."
Then we can start diving into the details of improving integration code
and build helpers to fix the problems they're seeing, with some concrete
feedback on whether we're getting it right or wrong.  I think this would
be more motivating than vague statements about portability issues that
aren't actionable.

-- 
Russ Allbery (r...@debian.org)   

Re: init system agnosticism [WAS: how to remove libsystemd0 from a live-running debian desktop system]

[Tollef Fog Heen]

]] Vincent Danjean 

>   For me, the first argument explain in the first mail is not this
> one. systemd is not portable on lots of system (hurd, kFreeBSD, ...),
> upstream systemd is not interested in making its code portable, nor to
> stabilize its interfaces so that other system init can easily
> implement them, [...]

While it's correct that systemd isn't catering to portability, large
chunks of it is covered by the interface stability promise (see the
table on
https://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/)
so other init systems are free to implement them if they so want.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Re: init system agnosticism [WAS: how to remove libsystemd0 from a live-running debian desktop system]

[Vincent Danjean]

  Hi,

  I do not have any strong position on this subject.

Le 13/04/2017 à 02:13, Russ Allbery a écrit :
> I guess I'm confused about what you think this email will accomplish.  I
> feel like it's just another round of being convinced that, since you
> dislike systemd, everyone else must also somehow dislike systemd too, deep
> down inside, and if you just find the right argument, all those people who
> think they like systemd will realize that they actually don't and will
> come help you build something else.

  For me, the first argument explain in the first mail is not this one.
systemd is not portable on lots of system (hurd, kFreeBSD, ...), upstream
systemd is not interested in making its code portable, nor to stabilize
its interfaces so that other system init can easily implement them, lots
of applications are now using libsystemd to get 'classical' information
(status, ...) because they do not want to have to deal with several init
system and porters of platforms not supported by systemd have a really hard
work to follow systemd developments and patch all things.

  For me, this seems a real issue (and, again, I do not know the good
way to deal with this).
  From your mail, you seems to deny this issue ("everybody can be pleased
with systemd" and/or "this is not a general problem, just a problem
from people that dislike systemd"). For what I see, it seems a problem
also for people that like systemd but cannot use it on their plate-form
(Hurd, ...)

  I'm persuaded that ignoring this issue will lead to an unmaintanable
Debian distribution on plateforms that do not support systemd in the
middle/long term. But, perhaps, it is what the project wants.
  Enrico is proposing something else. I'm not sure if his proposal is
good and doable (ie with enough support from various parties and
manpower).
  I'm not pleased at all with arguments to stop this discussion nor
with arguments that try to deny the issue. I do not know what can
really be done to solve the issue.

  Regards,
Vincent

Re: init system agnosticism [WAS: how to remove libsystemd0 from a live-running debian desktop system]

[Brian May]

On 2017-04-13 10:13, Russ Allbery wrote:

> It would be nice if people would stop doing the same thing over and over
> again and expecting different results.

Maybe this illustrates the core of the problem: https://xkcd.com/242/

Re: init system agnosticism [WAS: how to remove libsystemd0 from a live-running debian desktop system]

[Russ Allbery]

"Enrico Weigelt, metux IT consult"  writes:

> So, why don't we just ask, what kind of functionality do applications
> really want (and what's the actual goal behind), and then define open
> interfaces, that can be easily implemented anywhere ?

Who's we?

The people who are happy with systemd are, err, happy with systemd.  Most
of them aren't particularly interested in reinventing those wheels yet
again, given that they already have wheels that work pretty well.  Also,
the systemd interfaces look pretty open to me; you're entitled to
disagree with me, but I'm also entitled to disagree with *you* (and I do).

If you're trying to put together a development team of people to work on a
new init system, well, knock yourself out I guess, but I'm not sure this
is the best forum from which to try to recruit people.

I guess I'm confused about what you think this email will accomplish.  I
feel like it's just another round of being convinced that, since you
dislike systemd, everyone else must also somehow dislike systemd too, deep
down inside, and if you just find the right argument, all those people who
think they like systemd will realize that they actually don't and will
come help you build something else.  You're not going to get any farther
with this than the last dozen people who tried, and the constant attempts
are honestly kind of tiring and, human psychology being what it is,
probably make it even less likely that people will be willing to work on
some partial systemd replacement.

It would be nice if people would stop doing the same thing over and over
again and expecting different results.

-- 
Russ Allbery (r...@debian.org)   

Re: init system agnosticism [WAS: how to remove libsystemd0 from a live-running debian desktop system]

[Rowan Thorpe]

On 12 April 2017 at 09:38, Enrico Weigelt  wrote:
> ..[snip]..
> So, at least anybody who maintains and systemd-free environment (eg.
> platforms that dont even have it) needs run behind them and keep up.

I think what you say there answers your own question at the end of your
email about "...why people spent so much time in init system wars,
instead of thinking clearly of the actual root problem to solve". It seems
reminiscent of the days when web standardization had to play catch-up
to Netscape and Internet Explorer, sorting the wheat from the (bloat) chaff.
I suspect that "running behind", as you describe it, would be a thankless
and frustrating task, especially when on the level of PID 1 (as opposed to
just a browser), and it may not ever gain adoption or even enough
attention in the first place. I think a lot of the holy war that happened was
due to people sensing that situation on the horizon.

> ..[snip]..
> So, why don't we just ask, what kind of functionality do applications
> really want (and what's the actual goal behind), and then define open
> interfaces, that can be easily implemented anywhere ?

I would be keen (and I am sure many others would too) to help thrash
out a consensus-document somewhere, even if I suspect it will be an
arduous and largely thankless task. The key is that a very open,
transparent, and steady process needs to be established - with a
*strong* emphasis on pragmatic engineering, and active avoidance of
unnecessary politics, echo-chambers, vested interests, etc. I say
"unnecessary" because of course politics will come into it a lot of the
time, but that needs to be managed/contained to avoid the
soul-destroying sense of futility which comes when people get angry
and petty. Also, in order to hold on to any degree of relevance it would
have to be very inclusive and accommodating of existing systems,
which would involve often yielding to legacy over optimality, even when
it hurts on an intellectual level (see html5 vs. xhtml). Due to the
adoption/momentum systemd now has, it would have to be especially
heavily catered to, more than many people would "like", because
otherwise any efforts would just create yet another "elegant but
ignored" standard. I doubt I even need to link to this xkcd, because
you probably already have it in mind ;-)

 https://xkcd.com/927/

> All we need yet is an init-system/service-monitor
> agnostic API, that can be easily implemented w/o extra hassle.
> A simple reference implementation probably would just write some
> statfiles and/or log to syslog, others could talk to some specific
> service monitor.
>
> Having such an API (in its own library), we'd already have most of
> the problems here out of the way. Each init system / service monitor
> setup comes with some implementation of that API, and applications
> just depend on the corresponding package - everything else can be
> easily handled by the existing package management infrastructure.
> No need for recompiles (perhaps even no need to opt out in all the
> individual packages).
>
> The same can be done for all the other features currently used from
> libsystemd, step by step.
>
> Maintenance of these APIs (specification and reference implementation)
> should be settled in an open community (perhaps similar to
> freedesktop.org for the DE's), not in an individual init system /
> service monitor project.

I think the hardest part of all would be porting enough of the existing
systems to such an interface and *maintaining them* for long enough to
prove the endeavour is worthwhile, and to pressure them to do so
officially. Especially for systems under heavy development (like systemd)
that would involve an enormous amount of rebasing and merge-conflicts.
To put that in perspective, some of the systems according to wikipedia at
the moment are:

BootScripts, busybox-init, DEMONS, eINIT, Epoch, Initng, launchd,
Mudur, procd, nosh, OpenRC, runit, s6, Service Management Facility,
Shepherd, systemd, SystemStarter, Upstart.

I doubt any of them will voluntarily spend initial effort of their own
conforming to a new "proposal which hopes to become a standard some
day"...

On 12 April 2017 at 11:08, Jonas Smedegaard  wrote:
> Quoting Enrico Weigelt, metux IT consult (2017-04-12 08:38:26)
> > I really wonder why people spent so much time in init system wars,
> > instead of thinking clearly of the actual root problem to solve.
>
> Because the debate got derailed by remarks painting other contributors
> to the debate as idiots, perhaps?

As much as I agree with that sentiment, I suggest two things:

* If you intend to start such an effort I recommend doing it straight away,
  before this thread devolves into yet another depressing trail of vented
  frustrations (which inevitably leads to personal attacks and pettiness),
  which would stop people even clicking through to the project, and in the
  worst case just deciding to ignore the debian-dev mailing list completely
  (like I did for the few months following

Re: init system agnosticism [WAS: how to remove libsystemd0 from a live-running debian desktop system]

[Jonas Smedegaard]

Quoting Enrico Weigelt, metux IT consult (2017-04-12 08:38:26)
> I really wonder why people spent so much time in init system wars, 
> instead of thinking clearly of the actual root problem to solve.

Because the debate got derailed by remarks painting other contributors 
to the debate as idiots, perhaps?


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

init system agnosticism [WAS: how to remove libsystemd0 from a live-running debian desktop system]

[Enrico Weigelt, metux IT consult]

On 17.02.2015 18:49, The Wanderer wrote:

Hi folks,


just digging out an older thread that was still laying around in my
inbox - w/ about 2yrs distance, I hope it was enough cool down time
so we discuss it more objectively about that.



> libsystemd0 is not a startup method, or an init system. It's a shared
> library which permits detection of whether systemd (and the
> functionality which it provides) is present.

>From a sw architects pov, I've got a fundamental problem w/ that
appraoch: we'll have lots of sw that somehow has 'magically'
additional functionality if some other sw (in that case systemd)
happens to run.

The official description is: "The libsystemd0 library provides
interfaces to various systemd components." But what does that mean ?
Well, more or less a catchall for anything that somehow wants to
communicate w/ systemd. What this is actually for, isn't clear at all
at that point - you'll have to read the code yourself to find out.
And new functionality can be added anytime, and sooner or later some
application will start using it. So, at least anybody who maintains
and systemd-free environment (eg. platforms that dont even have it)
needs run behind them and keep up.

Certainly, systemd has a lot of fancy features that many people like,
but also many people dislike (even for exactly the same reaons).
The current approach adds a lot of extra load on the community and
causes unnecessary conflicts.

So, why don't we just ask, what kind of functionality do applications
really want (and what's the actual goal behind), and then define open
interfaces, that can be easily implemented anywhere ?

After looking at several applications, the most interesting part seems
to be service status reporting. Certainly an interesting issue that
deserves some standardization (across all unixoid OS'es). There're lots
of ways to do that under the hood - even without having to talk to some
central daemon (eg. extending the classical pidfile approach to
statfiles, etc). All we need yet is an init-system/service-monitor
agnostic API, that can be easily implemented w/o extra hassle.
A simple reference implementation probably would just write some
statfiles and/or log to syslog, others could talk to some specific
service monitor.

Having such an API (in its own library), we'd already have most of
the problems here out of the way. Each init system / service monitor
setup comes with some implementation of that API, and applications
just depend on the corresponding package - everything else can be
easily handled by the existing package management infrastructure.
No need for recompiles (perhaps even no need to opt out in all the
individual packages).

The same can be done for all the other features currently used from
libsystemd, step by step.

Maintenance of these APIs (specification and reference implementation)
should be settled in an open community (perhaps similar to
freedesktop.org for the DE's), not in an individual init system /
service monitor project.


I really wonder why people spent so much time in init system wars,
instead of thinking clearly of the actual root problem to solve.


--mtx

Re: how to remove libsystemd0 from a live-running debian desktop system

[Luke Kenneth Casson Leighton]

On Wed, Feb 18, 2015 at 12:16 AM, Axel Wagner  wrote:
> Luke Kenneth Casson Leighton  writes:
>>  what *does* concern me is that it takes such incredible (and amazing)
>> efforts by people like adam for the average end-user or sysadmin to
>> contemplate replacing {insert nameless package}.
>
> insert libc6.

 libc6 has alternatives, and, itself is maintained by a diverse group
(the FSF) with a reputation for respecting software freedom and
sufficient experience to know the ropes surrounding UNIX/POSIX.  even
google when developing android decided that the GPL was a horrible
virus, they didn't like libc6 and very kindly funded the creation of
an alternative.  also as a well-defined standard it would be
unbelievably stupid to attempt to deviate from it ("get creative").

 conclusion: we can trust the libc6 maintainers.

> Or insert perl.

 perl is maintained by an extremely experienced and diverse group of
developers.  they understand the responsibilities behind maintaining
and developing such a critical programming language.

 conclusion: we can trust the perl developers.

> Or insert linux-image.

 linux is developed by a hodge-podge bag of cat-like developers who
all, amazingly, pull together and get the job done.  they're also
headed by a team of incredibly responsible people who have had decades
of experience.

 conclusion: we can trust the linux kernel developers.

 a previous example given was SE/Linux.  i outlined a case where,
paradoxically, it can be demonstrated that we can trust the developers
behind SE/Linux.

 another example i was gives was grub.  grub has alternatives (lilo
and others): by inference this keeps them honest by way of
competition.  conclusion: we can trust the grub developers.

> And suddenly no on cares (not even you).

 the cases you give are ones where a rational analysis shows that the
people behind them can be trusted.  we can go at this for as long as
you feel it useful for you to do so, but i think you will find that,
in every case, the team behind the package engender our trust (trust
is *not* earned, btw: respect is earned.  trust is given.  always.
past performance != guarantee of future behaviour)

 but systemd is very, very different.  far from being able to find
reasons why the systemd team may be trusted, analysis by several
people shows that, sadly, the complete opposite is the case.

 unfortunately, the team behind the systemd project have demonstrated
time and time again that their focus is extremely narrow: Redhat
Desktop.

 one example (and there are many, many more):
 http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/

 just one good analysis of which is here:
 http://lists.busybox.net/pipermail/busybox/2011-September/076713.html


> You have to do better than this, sorry. Just that
> a package has reverse dependencies and that you have to recompile a big
> part of the debian archive to install a debian without them does *not*
> mean, that this package is in any way problematic
> [continued below]

 you are correct about that [i.e. you are correct in the assertion
that the recompilation for removal has nothing to do with removal].

  i am still trying to track down concrete reasons why i feel so
alarmed.  i believe it's because everything i've seen that team do -
all their "blogs" and reports has been... it feels so "rational", and
so "logical", yet nowhere do i see any kind of debate, inclusion of
other people, other teams.  do these people join mailing lists other
than those directly related to fedora desktop?

 the whole situation feels desperately, desperately wrong, and i
cannot unfortunately give you a single concrete specific example or
reason why, and that is part of the problem: nobody else really can,
either.

 and i think that's really why everyone has been getting so fed up,
getting into such severe arguments that they end up leaving projects
that they've worked well for decades with everyone for such a long
time.

that *in and of itself* should tell you that there's something
seriously wrong, here.  how many prominent, committed, dedicated and
experienced people have resigned from roles in debian so far - people
without whom debian is clearly worse off.

> [continued here]
> or takes away choice.

 on this you are wrong: by definition and by the immediate evidence
shown, it does exactly and precisely that.  [more specifically, the
choices that people are forced into making are so extreme that many
cannot even make them, they are so disruptive, or require such extreme
knowledge, or require extreme risks, or require violations of company
policy - use of unofficial archives which would violate support
contracts - and so on].

l.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAPweEDzfzUx=+hzezcgpomp7ufrogfbv4k9aa-oqao+ev1g...@mail.gmail.com

Re: how to remove libsystemd0 from a live-running debian desktop system

[Matthias Urlichs]

Hi,

Marc Haber:
> On Mon, 16 Feb 2015 22:31:19 +0100, m...@linux.it (Marco d'Itri) wrote:
> >As usual, the systemd critics are just misinformed. This comforts me. 
> >because it means that their views can be easily ignored.
> 
> And as usual, you don't make any effort to change the misinformation.

Well … I don't remember who's supposed to have said it, but one sign of
insanity is, if something you do doesn't work, to expect different results
when you do the same thing again.

This list's archive contains a multitude of such efforts.
So do other places on the net.

> Otoh, most systemd documentation lacks objectivity.
> 
So does any other documentation whose authors are convinced they're doing
something right. Would you demand a sidebar on gimp.org which praises the
cool features of Inkscape or Scribus?

-- 
-- Matthias Urlichs


signature.asc
Description: Digital signature

Re: how to remove libsystemd0 from a live-running debian desktop system

[Russ Allbery]

Simon Richter  writes:

> With my embedded hat on, it would be nice if there was an easy way to
> drop this extra dependency, as it means a lot of essentially dead code
> loaded on systems that don't use systemd.

Like others, I'd be happy to support that as a build profile or build
option or something.  As upstream, it's already easy to tell all my code
that's systemd-aware to stub out that stuff if wanted.

But, as you say, I think it's unlikely that this is really the low-hanging
fruit for very resource-constrained embedded environments.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/878ufupn32@hope.eyrie.org

Re: how to remove libsystemd0 from a live-running debian desktop system

[Marco d'Itri]

On Feb 18, Simon Richter  wrote:

> With my embedded hat on, it would be nice if there was an easy way to
> drop this extra dependency, as it means a lot of essentially dead code
> loaded on systems that don't use systemd.
http://anonscm.debian.org/cgit/users/md/libsystemd-dummy.git/

-- 
ciao,
Marco


pgp3qBNdAbYV6.pgp
Description: PGP signature

Re: how to remove libsystemd0 from a live-running debian desktop system

[Adam Borowski]

On Wed, Feb 18, 2015 at 07:21:44PM +0100, Simon Richter wrote:
> > If the argument is that it should be opened with dlopen at runtime, I'm
> > quite confident that there are *many* people on debian-devel who have
> > worked with shared libraries and can spell out many reasons why that's a
> > horrible idea.
> 
> As a systemd opponent, I'm fairly okay with programs being linked
> against libsystemd, in the same way that it is okay in my book to link
> libavahi, as long as you don't pull in the daemon itself.

Yeah, my exercise in excising it via --disable-systemd was to make sure no
undeclared dependency is left (those are rife in related code), rather than
to get rid of that small library.

> With my embedded hat on, it would be nice if there was an easy way to
> drop this extra dependency, as it means a lot of essentially dead code
> loaded on systems that don't use systemd.

_Currently_ there is: most affected packages have --disable-systemd, removal
of --enable-systemd, or that and massaging of debian/rules / control / etc.
I guess you'd want it encapsulated as some build profile flag.

It's not really relevant for even small non-embedded systems, though:
savings of 196KB disk space and a handful of RAM pages rarely has any
potential to be noticeable.  

> If you are sufficiently constrained on RAM, then udev stops looking like
> a great tool to set up /dev and starts looking like a huge blob of code
> that is essentially only used for the system to speak to itself.

vdev, an udev replacement in the making, has an --one-shot mode where it
populates /dev/ and immediately exits.  I guess this might be doable with
udev or busybox mdev, too, if you let them settle then kill them.


-- 
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150218205009.ga23...@angband.pl

Re: how to remove libsystemd0 from a live-running debian desktop system

[Simon Richter]

Hi,

Am 18.02.2015 um 04:32 schrieb Russ Allbery:

> If the argument is that it should be opened with dlopen at runtime, I'm
> quite confident that there are *many* people on debian-devel who have
> worked with shared libraries and can spell out many reasons why that's a
> horrible idea.

Correct.

As a systemd opponent, I'm fairly okay with programs being linked
against libsystemd, in the same way that it is okay in my book to link
libavahi, as long as you don't pull in the daemon itself.

With my embedded hat on, it would be nice if there was an easy way to
drop this extra dependency, as it means a lot of essentially dead code
loaded on systems that don't use systemd.

If you are sufficiently constrained on RAM, then udev stops looking like
a great tool to set up /dev and starts looking like a huge blob of code
that is essentially only used for the system to speak to itself.

I don't see it as that urgent though, because Debian is still
sufficiently inflexible in many other places that it makes sense to keep
a fork-and-patch infrastructure in place anyway. In the long run though,
it would be nice if it were possible to push as many of these changes
back into Debian proper as configuration options, in order to reduce the
overhead of derivatives.

   Simon



signature.asc
Description: OpenPGP digital signature

Re: how to remove libsystemd0 from a live-running debian desktop system

[Scott Kitterman]

On February 18, 2015 7:54:00 AM EST, Luke Kenneth Casson Leighton 
 wrote:
>On Wed, Feb 18, 2015 at 12:27 AM, Steve Langasek 
>wrote:
>> On Tue, Feb 17, 2015 at 11:52:21PM +, Luke Kenneth Casson
>Leighton wrote:
>>> On Tue, Feb 17, 2015 at 10:52 PM, Josh Triplett
> wrote:
>>
>>> > So, please go educate yourself on what libsystemd0 actually does,
>>
>>>  i know what it does, and what it does - technically - is *not* the
>>> issue that i am concerned about.
>>
>> And that is why you'll find little interest here in entertaining your
>> argument.  You have *not* presented any evidence that Debian is
>technically
>> worse off as a result of packages depending on libsystemd0.
>
> that's right - i haven't.  because (a) i have complete confidence in
>your technical abilities, as a group.  i wouldn't use debian
>otherwise! :)  and (b) this isn't a technical issue, it's a strategic
>one.
>
> so, the gist is: debian developers make decisions primarily based on
>technical merit (almost exclusively), disregarding strategic issues
>(almost exclusively).  would that be a fairly broad but accurate
>assessment? (thank you to everyone else who has chipped in, i read a
>couple of other messages from people which point in a similar
>direction)
>
> a couple of things occur to me.
>
> firstly, when i was last in holland i was working for NC3A, some kind
>person referred me to an obscure book called "The Strategy-focussed
>Organisation".  very intelligent guy, who had actually read it... i
>don't recommend reading all of it cover-to-cover, and neither did he
>:)
>
> he pointed out to me the one key question is that when it comes to
>the strategy (direction, focus) of any organisation, the question "why
>should we care what anyone else is doing?" is *the* most important one
>you can possibly ask.  why - when you, the debian developers, are
>doing such a fantastic job (really and sincerely) - should you care
>when someone from *outside* of your group jumps up and down and says
>"uhh... guuuys?"
>
> i invite you to think seriously about that, ok?  (because i don't
>have an answer!!)
>
> the second thing - and i'm taking a huge risk here by using the
>example that i'm about to share with you; please DO NOT think for ONE
>SECOND that you are being ACCUSED of anything, ok?  i'm using this
>example because i believe it will get through to you with enough
>clarity.  i DO NOT want to hear ANYONE say "god almighty, did he
>_really_ just accuse us of being horrible people by association", ok?
>
> do you know what the world's most authoritative medical texts are on
>the subject of pain?  pain thresholds, tolerance, stress levels and so
>on?  it's the documentation that the nazis made during their reign.
>horrifyingly, they were *genuinely curious*, but, unlike other groups
>who have tortured other humans, they meticulously documented all of
>their work.
>
> why am i mentioning this example?  because, *technically*, the nazis
>documentation of their work is sufficiently flawless as to be of
>extremely high *technical* value in the medical world, even today.
>
> ... but does that mean that *strategically* they should even have
>been doing that research in the first place?  does the *technical*
>quality of their work justify their torturing and murdering of other
>human beings, just to see what happened??  of *course* it f*g well
>doesn't!
>
> so this extreme example should, i believe, serve as an extremely
>graphic illustration that, in any group, technical decisions need to
>be guided by some sort of moral and/or strategic compass.  not
>that i claim to be an authority on either [1].
>
>would you agree with that?  i mean the moral and strategic compass
>bit, not my claim to not be an authority on moral compasses :)
>
>l.
>
>[1] please don't say i am claiming to tell you what to do, therefore
>you have the right to ignore it. as a group you keep doing that, and i
>keep having to tell you i'm not, and it's getting really, really old.

The comparison drawn in this message is indicative of both a stunning lack of 
perspective and a stunning ignorance of history. Please go learn some history 
and ponder how ridiculous this is. 

Once Godwin's law is fulfilled, the thread is over and whoever did it lost.

Stop.

I'd ask our listmasters to enforce this if needed. 

Scott K


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/2706249b-fad9-4259-bbd7-453054d48...@kitterman.com

Re: how to remove libsystemd0 from a live-running debian desktop system

[Christian Kastner]

On 2015-02-18 13:54, Luke Kenneth Casson Leighton wrote:
>  that's right - i haven't.  because (a) i have complete confidence in
> your technical abilities, as a group.  i wouldn't use debian
> otherwise! :)  and (b) this isn't a technical issue, it's a strategic
> one.

No, it's not. The issue is (c) that you erected a huge strawman, which
you proceeded to publicize the hell out of. And having the fallacy of
your argument pointed out to you about a dozen times now, you keep
trying to invent new arguments instead of just letting it go.

Please. Just acknowledge that this whole "removing libsystemd0" thing
was nonsense and move on to something more productive, like finding a
real bug.

>  do you know what the world's most authoritative medical texts are on
> the subject of pain?  pain thresholds, tolerance, stress levels and so
> on?  it's the documentation that the nazis made during their reign.
> horrifyingly, they were *genuinely curious*, but, unlike other groups
> who have tortured other humans, they meticulously documented all of
> their work.

I'd like to invoke Godwin's Law.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/4362a7db2717b3ed887e4afdbff29...@kvr.at

Re: how to remove libsystemd0 from a live-running debian desktop system

[Luke Kenneth Casson Leighton]

On Wed, Feb 18, 2015 at 12:27 AM, Steve Langasek  wrote:
> On Tue, Feb 17, 2015 at 11:52:21PM +, Luke Kenneth Casson Leighton wrote:
>> On Tue, Feb 17, 2015 at 10:52 PM, Josh Triplett  
>> wrote:
>
>> > So, please go educate yourself on what libsystemd0 actually does,
>
>>  i know what it does, and what it does - technically - is *not* the
>> issue that i am concerned about.
>
> And that is why you'll find little interest here in entertaining your
> argument.  You have *not* presented any evidence that Debian is technically
> worse off as a result of packages depending on libsystemd0.

 that's right - i haven't.  because (a) i have complete confidence in
your technical abilities, as a group.  i wouldn't use debian
otherwise! :)  and (b) this isn't a technical issue, it's a strategic
one.

 so, the gist is: debian developers make decisions primarily based on
technical merit (almost exclusively), disregarding strategic issues
(almost exclusively).  would that be a fairly broad but accurate
assessment? (thank you to everyone else who has chipped in, i read a
couple of other messages from people which point in a similar
direction)

 a couple of things occur to me.

 firstly, when i was last in holland i was working for NC3A, some kind
person referred me to an obscure book called "The Strategy-focussed
Organisation".  very intelligent guy, who had actually read it... i
don't recommend reading all of it cover-to-cover, and neither did he
:)

 he pointed out to me the one key question is that when it comes to
the strategy (direction, focus) of any organisation, the question "why
should we care what anyone else is doing?" is *the* most important one
you can possibly ask.  why - when you, the debian developers, are
doing such a fantastic job (really and sincerely) - should you care
when someone from *outside* of your group jumps up and down and says
"uhh... guuuys?"

 i invite you to think seriously about that, ok?  (because i don't
have an answer!!)

 the second thing - and i'm taking a huge risk here by using the
example that i'm about to share with you; please DO NOT think for ONE
SECOND that you are being ACCUSED of anything, ok?  i'm using this
example because i believe it will get through to you with enough
clarity.  i DO NOT want to hear ANYONE say "god almighty, did he
_really_ just accuse us of being horrible people by association", ok?

 do you know what the world's most authoritative medical texts are on
the subject of pain?  pain thresholds, tolerance, stress levels and so
on?  it's the documentation that the nazis made during their reign.
horrifyingly, they were *genuinely curious*, but, unlike other groups
who have tortured other humans, they meticulously documented all of
their work.

 why am i mentioning this example?  because, *technically*, the nazis
documentation of their work is sufficiently flawless as to be of
extremely high *technical* value in the medical world, even today.

 ... but does that mean that *strategically* they should even have
been doing that research in the first place?  does the *technical*
quality of their work justify their torturing and murdering of other
human beings, just to see what happened??  of *course* it f*g well
doesn't!

 so this extreme example should, i believe, serve as an extremely
graphic illustration that, in any group, technical decisions need to
be guided by some sort of moral and/or strategic compass.  not
that i claim to be an authority on either [1].

would you agree with that?  i mean the moral and strategic compass
bit, not my claim to not be an authority on moral compasses :)

l.

[1] please don't say i am claiming to tell you what to do, therefore
you have the right to ignore it. as a group you keep doing that, and i
keep having to tell you i'm not, and it's getting really, really old.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/capweedyrutzfv9wu2pouktngl6ckbdoisetqgla-etdzyi1...@mail.gmail.com

Re: how to remove libsystemd0 from a live-running debian desktop system

[Ondřej Surý]

On Wed, Feb 18, 2015, at 04:32, Russ Allbery wrote:
> (Removing every package whose name contains the string "systemd" is not a
> practical, useful purpose.  It's just silly.)

Perhaps we could rename the library (and the package) to:

libthis-is-not-the-library-you-are-looking-for.so.0

I guess that would stop the random hate from running "dpkg -l | grep
systemd" :)

O.
-- 
Ondřej Surý 
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1424261644.2845303.229175829.4b261...@webmail.messagingengine.com

Re: how to remove libsystemd0 from a live-running debian desktop system

[Johannes Schauer]

Hi,

Quoting Didier 'OdyX' Raboud (2015-02-17 21:31:05)
> Le lundi, 16 février 2015, 13.38:01 Adam Borowski a écrit :
> > Second, all but one (upower) of affected packages can be recompiled to
> > drop the dependency.  If you bothered to read lists you're subscribed
> > to, you would probably know of my set of deinfected packages at:
> >  deb http://angband.pl/debian nosystemd
> >  deb-src http://angband.pl/debian nosystemd
> > which are included for example in Trios.  After such a recompilation,
> > you can have a systemd-free system with no functionality loss -- in
> > fact, it does solve some regressions compared to systemd-using hacks
> > like -shim.
> 
> Given a common interface (such as 'nosystemd' in DEB_BUILD_OPTIONS), 
> I, for one, would most probably include (whishlist-level) patches 
> reducing this repetitive work to needing to set up automatic buildds 
> setting the correct options.

build profiles would be a better fit for such a mechanism. You could then even
conditionally include or exclude build dependencies depending on whether or not
the build profile "nosystemd" is active or enable or disable certain binary
packages being built.

This would "abuse" build profiles to work more like Gentoo USE flags. I talked
about that idea a bit in this thread:

http://lists.debian.org/20141212114840.15300.27739@hoothoot

I'm not endorsing this idea but just wanted to point out that this would be a
technically superior solution to encoding this in DEB_BUILD_OPTIONS. This would
for example also make it possible for downstreams of Debian which want a
"systemd free" derivative to contribute their modifications back into Debian.
The only difference they would then have is, that their buildds would build
packages with DEB_BUILD_PROFILES=nosystemd set.

cheers, josch


signature.asc
Description: signature

Re: how to remove libsystemd0 from a live-running debian desktop system

[Russ Allbery]

Nathan Schulte  writes:
> On 02/17/2015 11:49 AM, The Wanderer wrote:

>> libsystemd0_is_  dynamically loaded, precisely so that userspace
>> applications can make the decision at runtime as to what to do.

> What about dynamically linked?  Maybe Luke means dynamic linking
> (necessitating dynamic loading) instead?

It's already dynamically linked too.

If the argument is that it should be opened with dlopen at runtime, I'm
quite confident that there are *many* people on debian-devel who have
worked with shared libraries and can spell out many reasons why that's a
horrible idea.  And it serves no practical, useful purpose.  (Removing
every package whose name contains the string "systemd" is not a practical,
useful purpose.  It's just silly.)

What Luke spent thousands of words advocating for is basically what the
systemd upstream has *already done* with libsystemd0.  One could even say
that it's a primary *purpose* of that library.  So, yay, I guess?  The
world is much better than you had thought and already as good as the
compromise position you thought you could get!

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87k2zfvqqp@hope.eyrie.org

Re: how to remove libsystemd0 from a live-running debian desktop system

[Nathan Schulte]

On 02/17/2015 07:36 PM, j...@joshtriplett.org wrote:
> I'm all out of patience now, and I no longer have any hope that you
> actually care about being taken seriously.  I have no plans to respond
> to any future mails from you.

Hey Josh,

Thanks for taking the time to write that up.  I'm a user*, and I respect 
Luke's premise.  I think we all do, honestly.


It's not choice for choice's sake, it's choice for the user's sake; 
there are users actively requesting (and using!) these features.  I 
don't know about libpam/etc. alternatives, but I imagine some of those 
don't exist due to licensing reasons or lack of user request.  I'm not 
sure; I wouldn't be surprised if it was actually similar to the case here.


I agree with the arguments about libsystemd0 as well (that it's not a 
valid concern).  At some point we all have to stop debating and play 
ball and get things done.  That tends to mean that the doers are also 
the sayers; that's just the way it works.  Debian does a great job of 
swaying that balance toward the user, and I expect and hope it will 
continue to do so.  I don't agree with the boycotts, the forks in that 
vein tend to only detract.  I guess the boycotters aren't also in favor 
of choice?  Some strange intersection of groups coming out on the 
mailing lists these days...


Anyway, sorry for testing your patience, and thanks for your input.  I 
have some more reading to do it seems.


--
Nate

* a user that wishes he contributed more; I try to support the bugs I 
create in the form of code, but usually the bugs I create involve 
systems that are far too complex for the uninitiated to begin to help 
with, especially if they can't sink in for the long haul.



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54e4061b.7070...@gmail.com

Re: how to remove libsystemd0 from a live-running debian desktop system

[josh]

On Tue, Feb 17, 2015 at 11:52:21PM +, Luke Kenneth Casson Leighton wrote:
> On Tue, Feb 17, 2015 at 10:52 PM, Josh Triplett  wrote:
> > So, please go educate yourself on what libsystemd0 actually does,
> 
>  i know what it does, and what it does - technically - is *not* the
> issue that i am concerned about.

Then you've given no reason whatsoever for anyone to remove it.  Because
without that, all the same arguments apply to how hard it would be to
remove PAM, glibc, glib, or many other libraries, most of which would be
even harder to remove than libsystemd0.

>From current unstable:

~$ aptitude search '?depends(libsystemd0)' -F '%p' | wc -l
70

If you're going to artificially inflate that number by talking recursive
reverse-dependencies, then I would suggest that you look at the
number of packages removed by attempting to remove libpam0g, or
libglib2.0-0, or libc6.  By any reasonable definition, those are not
"optional" either.

> > and if
> > for some reason you still consider it a problem after doing so, you'll
> > need to explain why,
> 
>  i have done so, a number of times.  take away the name of the
> library.  take away what it does.  take away how it does it, because
> none of those things are relevant.

Apparently they are, to you, or you'd be making the same rant about
something that didn't contain the substring "systemd".

>  what *does* concern me is that it takes such incredible (and amazing)
> efforts by people like adam for the average end-user or sysadmin to
> contemplate replacing {insert nameless package}.

And you've now completely ignored my question.  If you want people to
*care* that it's hard to remove libsystemd0, you'll have to explain why
anyone would *want* to remove libsystemd0.  There exist a pile of other
libraries in Debian that have far more reverse dependencies and would
take much more work to remove.

>  that *is* the problem.  i'm aware that there are many people in key
> positions in debian who do not see this lack of choice as being the
> problem, but i can assure you that it is.

Your assertions have little to no credibility; even less every time you
write a new mail in this thread.  I've already seen evidence (in the
form of mails in this very thread) demonstrating that people who have
said in the past they care about preserving non-systemd init systems
(e.g. Russ) do *not* see the point of avoiding dependencies on
libsystemd0.  So you're currently arguing "on behalf" of a niche of a
niche, and you're doing absolutely nothing to explain why the subset of
users who don't want libsystemd0 installed (which thus far appears to
contain 2-3 users) is worth a *disproportionate* amount of development
time.

> > because as demonstrated in this thread, even those
> > developers in Debian who still do care about non-systemd systems do not
> > agree with you that it's a problem.  See, for instance, Russ's response,
> > which you lauded while failing to actually comprehend, since you seem to
> > believe that his response described something that needed changing
> > rather than describing the current state.
> 
>  i believe tiredness may be affecting my ability to understand the
> point you're trying to make, here.  i'm genuinely pleased that russ
> (and adam) came up with the same possible solution (dynamic library
> loading) that, if deployed, would end this entire issue because it
> would allow people to make a choice.

If you're (intentionally or unintentionally) misinterpreting Russ's mail
as suggesting that dlopen would be a good idea, let's stop talking past
each other: no, that'd be a bad idea, since the amount of additional
code needed to do so would make the use of libsystemd0 more painful,
when libsystemd0 is not a sufficiently large or invasive library to
warrant that.  libsystemd0 exists to avoid having to write duplicate
code in numerous programs; adding more such duplicate code to use dlopen
would defeat the purpose.  We use dlopen for libraries that are either
1) absurdly huge, 2) have unwanted dependencies, or 3) have issues that
prevent depending on them (such as libdvdcss).

libsystemd0 itself is specifically designed to not depend on any other
component of systemd; libsystemd0 *is* the thing you link to to
*optionally* use systemd functionality.  And you still have yet to
explain why anyone would need to remove it.  (Arguments against systemd,
credible or otherwise, do not automatically apply to libsystemd0.)

I'm all out of patience now, and I no longer have any hope that you
actually care about being taken seriously.  I have no plans to respond
to any future mails from you.

If you *do* end up caring about being taken seriously, I would suggest
that you re-read my previous response, and take some action in response
to it *other* than replying, ideally involving 1) some research and 2)
some understanding of basic mailing list etiquette.  Consider in
particular the mental models that other people might use to classify the
usefulness and credibility of your 

Re: how to remove libsystemd0 from a live-running debian desktop system

[Steve Langasek]

On Tue, Feb 17, 2015 at 11:52:21PM +, Luke Kenneth Casson Leighton wrote:
> On Tue, Feb 17, 2015 at 10:52 PM, Josh Triplett  wrote:

> > So, please go educate yourself on what libsystemd0 actually does,

>  i know what it does, and what it does - technically - is *not* the
> issue that i am concerned about.

And that is why you'll find little interest here in entertaining your
argument.  You have *not* presented any evidence that Debian is technically
worse off as a result of packages depending on libsystemd0.

> take away the name of the library.  take away what it does.  take away how
> it does it, because none of those things are relevant.

>  what *does* concern me is that it takes such incredible (and amazing)
> efforts by people like adam for the average end-user or sysadmin to
> contemplate replacing {insert nameless package}.

>  that *is* the problem.  i'm aware that there are many people in key
> positions in debian who do not see this lack of choice as being the
> problem, but i can assure you that it is.

Your assurances here are unpersuasive.  Choice for choice's sake is NOT an
objective of Debian.  And your proposal is worse than that; it's not giving
users a real choice at all, because the only alternative you're offering
besides integration with systemd is software NOT integrating with systemd. 
This provides no technical value to our users, and is nothing but a sop to
those who object to the string 'systemd' appearing in their dpkg output.

You can waste your own time on such pointless pursuits if you wish.  But
stop wasting ours.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: how to remove libsystemd0 from a live-running debian desktop system

[Axel Wagner]

Luke Kenneth Casson Leighton  writes:
>  what *does* concern me is that it takes such incredible (and amazing)
> efforts by people like adam for the average end-user or sysadmin to
> contemplate replacing {insert nameless package}.

insert libc6. Or insert perl. Or insert linux-image. And suddenly no one
cares (not even you). You have to do better than this, sorry. Just that
a package has reverse dependencies and that you have to recompile a big
part of the debian archive to install a debian without them does *not*
mean, that this package is in any way problematic or takes away choice.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/87vbj0845z.fsf@rincewind.i-did-not-set--mail-host-address--so-tickle-me

Re: how to remove libsystemd0 from a live-running debian desktop system

[Luke Kenneth Casson Leighton]

On Tue, Feb 17, 2015 at 10:52 PM, Josh Triplett  wrote:

> So, please go educate yourself on what libsystemd0 actually does,

 i know what it does, and what it does - technically - is *not* the
issue that i am concerned about.

> and if
> for some reason you still consider it a problem after doing so, you'll
> need to explain why,

 i have done so, a number of times.  take away the name of the
library.  take away what it does.  take away how it does it, because
none of those things are relevant.

 what *does* concern me is that it takes such incredible (and amazing)
efforts by people like adam for the average end-user or sysadmin to
contemplate replacing {insert nameless package}.

 that *is* the problem.  i'm aware that there are many people in key
positions in debian who do not see this lack of choice as being the
problem, but i can assure you that it is.

> because as demonstrated in this thread, even those
> developers in Debian who still do care about non-systemd systems do not
> agree with you that it's a problem.  See, for instance, Russ's response,
> which you lauded while failing to actually comprehend, since you seem to
> believe that his response described something that needed changing
> rather than describing the current state.

 i believe tiredness may be affecting my ability to understand the
point you're trying to make, here.  i'm genuinely pleased that russ
(and adam) came up with the same possible solution (dynamic library
loading) that, if deployed, would end this entire issue because it
would allow people to make a choice.

 ah.  i got it.  i worked it out.  the sentence that bothered me was
the one which implied that no change is possible.  or desirable.  i
leave it to you over the next few weeks and months to assess whether
that assertion is true or not: when people continue, over the next few
weeks and months to *not* stop talking about systemd, remember this
moment, yeah?

> We used to build a half-dozen versions of libsdl, with support for
> various libraries, just so that people could avoid installing unused
> libraries on their systems.  We don't do that anymore; if you install a
> program based on libsdl, you'll get libsdl1.2debian, which depends on
> libasound2 and libpulse0 and libdirectfb-1.2-9 and libx11-6 and other
> libraries.  If you always run against X with ALSA, and never run with
> DirectFB or PulseAudio, then you get a couple of extra libraries on your
> system.  Worth it so that libsdl doesn't have to build a half-dozen
> conflicting binary packages.

 great!  sounds like a sensible decision to me.

 question.  is libsdl on a par with sysvinit, openrc, systemd and
depinit?  no it isn't, is it.  if you run a server, do you *really*
need libsdl?  no you don't, do you.

 and, y'know what: another thing - the very fact that there *is*
choice within libsdl - a lot of it - different backends, different
graphics, different sound libraries, that's... that's fantastic!

 ... because it's everything that systemd is not.

 right now, my deepest concern is that there isn't any other choice.
do you not also perceive that as being a problem?


> You should also learn what the word "unilateral" means; for someone
> willing to pedantically post a link to a dictionary, you seem to have
> failed to read it.  Distributions and projects have independently (or,
> if you like, *multilaterally*) started using systemd because it works
> well for them.

 yyyeah... i know - because they all took what the upstream developers
provided and they all ripped out everything *but* systemd.

 and that means we're into a monoculture.

 do you see that that is a problem?  to make it clear: under what
circumstances has a monoculture traditionally and historicallybeen a
problem, under software-related (and non-software-related)
circumstances?


>  And yes, that means they use libsystemd0, whether or not
> they depend on PID 1 at runtime.  Your incredulity at how that managed
> to happen does not actually refute that it did.

 i never said that it did, nor was i incredulous at how it happened.
i believe i've posted a number of times - twice on this list -
indicating that i have been keeping an eye on this for some time, and
also analysed retrospectively what happened.  *at no time* did i post
any kind of unrealistic statements "how did that happen??" i can see
very clearly how it happened, and, importantly - twice at least - i've
gone to some lengths to say that i don't consider it to be anyone's
fault.

 ... where on earth are you getting this stuff about "how incredulous
i am" from, josh? :)  *puzzled and tired*...

l.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/capweedxmemkdlgrfzng2oa0sibfawl2rrtp261avbyx40xu...@mail.gmail.com

Re: how to remove libsystemd0 from a live-running debian desktop system

[Josh Triplett]

It's not the fact that you wrote such a long email that is necessarily
the problem; it's that you've shown no signs of either reading or
comprehending most of what people have actually said to you.  Instead,
you launched into a new set of diatribes that show very little sign of
having actually learned anything from anyone in the thread, including
the people you're quoting.

You seem to be complaining that people have failed to educate you.  Bear
in mind that many developers have spent so much time attempting to
educate systemd opponents (a rather thankless task), and at this point
have the very reasonable expectation that people will spend at least a
little time educating themselves.  This might be the first time *you're*
demanding such explanations, but it might be the four-hundredth time
that the person responding to has given such explanations, hence the
lack of remaining patience.  Tone down your sense of entitlement, as
well as your claim to be speaking for people other than yourself.

All that said, the much bigger concern is that you seem to be resistant
to *actually being educated* after demanding such from other people.
Such clue-resistance, together with your writing style (optimized for
your own writing rather than others reading), rants, entitlement,
condescension, taking Slashdot seriously, posting links to dictionary
entries you clearly haven't read, and various other factors, leads you
to being dismissed as a crank.  If you want to be taken seriously, fix
those things before you come back.  And if you *don't* want to be taken
seriously, then please don't come back at all.

For instance:

Luke Kenneth Casson Leighton wrote:
> understanding or otherwise how systemd works is not the point:
> the point is that there has been a unilateral decision across
> virtually every single GNU/Linux distro to abandon and remove *any*
> alternative to having libsystemd0 installed.
[...]
> i'm asking "why does *only* having libsystemd0 as the
> sole exclusive startup method

First, that you consider libsystemd0 a problem, or a "startup method",
shows that you *do* need to take more time understanding how systemd
works.  libsystemd0 exists largely to talk to systemd components if
present; linking to it does not mandate the use of systemd as PID 1, nor
does libsystemd0 actually start other processes.  Go read the (very well
documented) headers in /usr/include/systemd/sd-*.h .  Among other
things, libsystemd0 contains a function sd_booted() to check if the
system actually runs systemd, so that applications don't have to
reinvent such logic themselves.

So, please go educate yourself on what libsystemd0 actually does, and if
for some reason you still consider it a problem after doing so, you'll
need to explain why, because as demonstrated in this thread, even those
developers in Debian who still do care about non-systemd systems do not
agree with you that it's a problem.  See, for instance, Russ's response,
which you lauded while failing to actually comprehend, since you seem to
believe that his response described something that needed changing
rather than describing the current state.

We used to build a half-dozen versions of libsdl, with support for
various libraries, just so that people could avoid installing unused
libraries on their systems.  We don't do that anymore; if you install a
program based on libsdl, you'll get libsdl1.2debian, which depends on
libasound2 and libpulse0 and libdirectfb-1.2-9 and libx11-6 and other
libraries.  If you always run against X with ALSA, and never run with
DirectFB or PulseAudio, then you get a couple of extra libraries on your
system.  Worth it so that libsdl doesn't have to build a half-dozen
conflicting binary packages.

You should also learn what the word "unilateral" means; for someone
willing to pedantically post a link to a dictionary, you seem to have
failed to read it.  Distributions and projects have independently (or,
if you like, *multilaterally*) started using systemd because it works
well for them.  And yes, that means they use libsystemd0, whether or not
they depend on PID 1 at runtime.  Your incredulity at how that managed
to happen does not actually refute that it did.

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150217225200.GA6351@jtriplet-mobl1

Re: how to remove libsystemd0 from a live-running debian desktop system

[Alberto Garcia]

On Mon, Feb 16, 2015 at 01:54:35AM +, Luke Kenneth Casson Leighton wrote:

> you have the right to choose whether the situation that you are
> complicit in is something that you find acceptable or whether you do
> not. i leave it entirely to you to decide.

As a matter of fact we have already decided.

The status of systemd within Debian has already been discussed at
length (and voted), and points of view like yours have been expressed
many times in the past.

Please be more considerate before bringing this topic back again, and
particularly before suggesting that the developers of Debian are in
denial or unaware of the situation of the project.

Users are entitled to disagree with the direction of Debian and stop
using it, and developers also have the right to ignore opinions if
they feel that they don't contribute anything new.

And since that is the case here, this is my first and last message in
this thread.

Berto


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150217205713.ga4...@igalia.com

Re: how to remove libsystemd0 from a live-running debian desktop system

[Brett Parker]

On 17 Feb 17:44, Luke Kenneth Casson Leighton wrote:
>  thanks for pointing that out, claude - it helps that it was someone
> else who pointed out that being uncivil by asking a *person* to go
> away doesn't make the *problem* go away.
> 
>  andrew: i will go away only when i am satisified that the problem
> which i believe it is my duty and responsibility to help highlight and
> fix has, in fact gone away.

Well, if you're going to stay and waffle on incoherently, can you at
least learn to use some capital letters at the beginning of sentences.

Oh, and to stop waffling, do some research on what you're complaining
about, and form a coherent idea rather than write long paragraphs that
no one wants to read, and will send most people to sleep.

So far, your entire set of posts have been, to say the least, tedious
and already covered in other threads. Please go read *all* the other
threads that there have been on this, and *then* and *only then* think
about carrying on.

Sheesh,
-- 
Brett Parker


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150217201750.GF29573@miranda

Re: how to remove libsystemd0 from a live-running debian desktop system

[Didier 'OdyX' Raboud]

Le lundi, 16 février 2015, 13.38:01 Adam Borowski a écrit :
> Second, all but one (upower) of affected packages can be recompiled to
> drop the dependency.  If you bothered to read lists you're subscribed
> to, you would probably know of my set of deinfected packages at:
>  deb http://angband.pl/debian nosystemd
>  deb-src http://angband.pl/debian nosystemd
> which are included for example in Trios.  After such a recompilation,
> you can have a systemd-free system with no functionality loss -- in
> fact, it does solve some regressions compared to systemd-using hacks
> like -shim.

Given a common interface (such as 'nosystemd' in DEB_BUILD_OPTIONS), 
I, for one, would most probably include (whishlist-level) patches 
reducing this repetitive work to needing to set up automatic buildds 
setting the correct options.

I'm mostly happy with systemd, but unhappy when people go monkey-patch a 
lot of packages when scalable and maintainable solutions could make 
everyone's life easier. Sure, including patches for build-time toggling 
of systemd support slightly increases the maintenance, but now that we 
have VCS'es everywhere, I tend to think it's mostly a one-time work.

Cheers,
OdyX


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/2118253.4PMAVtGAYT@gyllingar

Re: how to remove libsystemd0 from a live-running debian desktop system

[Luke Kenneth Casson Leighton]

On Tue, Feb 17, 2015 at 6:25 PM, Luke Kenneth Casson Leighton
 wrote:

> which should help answer the question you asked: your work - fantastic
> as it is - was *impossible to find*.  it doesn't even remotely come up
> on the radar of queries.  *nobody knows what you've achieved* and
> that's something i would like to help correct.

 ok done:  http://neofutur.net/systemd-vault
 also i've edited http://without-systemd.org/wiki/index.php/Main_Page
adding a sentence that, i hope, allows what you did, adam, to be
easily distinguished from all the "forks" and rather challenging
alternatives to consider (including the inconvenience of moving away
from debian entirely).

l.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/capweedzscrh+mfp93+4xgkh2klbpxewmzfiizqpnpv7y5o+...@mail.gmail.com

Re: how to remove libsystemd0 from a live-running debian desktop system

[Luke Kenneth Casson Leighton]

On Tue, Feb 17, 2015 at 7:03 PM, Andrew Shadura  wrote:
> Hello,
>
> I'd like to apologise for my mail I sent about two hours ago. I have
> overreacted mainly because of the length of the email, CAPS INSIDE and
> also because it's a topic which is being discussed for more than a year
> and which many of people here are already tired of.

 i know, andrew.  i've been following it from a distance, staying away
until i had a better handle on what's going on, and a clue about
possible solutions.  i'm writing to the systemd developers now.

>
> I however still think that such lengthy writeups do really belong
> somewhere else, maybe to a blog, with a short post with a link being
> posted here.

  yehh, i wasn't expecting it to be that long - i lost track of
time, but also i wanted to make sure i addressed and included everyone
who responded over the past couple of days.

> Luke, Claude and everyone else, I am really sorry.

 not a problem andrew.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAPweEDyfnUwFTD2dde36DM2Ay2jQVv=pfsoozqqmo7_n_mc...@mail.gmail.com

Re: how to remove libsystemd0 from a live-running debian desktop system

[Andrew Shadura]

Hello,

I'd like to apologise for my mail I sent about two hours ago. I have
overreacted mainly because of the length of the email, CAPS INSIDE and
also because it's a topic which is being discussed for more than a year
and which many of people here are already tired of.

I however still think that such lengthy writeups do really belong
somewhere else, maybe to a blog, with a short post with a link being
posted here.

Luke, Claude and everyone else, I am really sorry.

-- 
Cheers,
  Andrew


pgpIiI4Oa2J4C.pgp
Description: OpenPGP digital signature

Re: how to remove libsystemd0 from a live-running debian desktop system

[Nathan Schulte]

On 02/17/2015 11:49 AM, The Wanderer wrote:

You only harm your case by misusing and confusing terminology in that
way.


>russ writes:
>

>>Alas, the resulting distribution is still hopelessly compromised by
>>the NSA, who might be even worse than Lennart Poettering.  To see
>>how deep the tendrils of US government infiltration go, just try
>>removing libselinux1, and marvel at how much concerted malevolent
>>effort has gone into destroying your freedom.

>
>and:
>

>>Or, alternately, you could research how and why one would use
>>shared libraries in a binary distribution to support optional
>>features.  But that's boring, prosaic, and nowhere near as much fun
>>to write about.

>
>ahhh russ - good maaan:)   here we have a hint of a possible
>solution, one where i'm going to need to speak to the systemd team
>for a feature request / design decision (and can i ask you and anyone
>else to do the same?).  you've hit on what i believe is*the*  perfect
>and acceptable decision that is hinted at by the ridiculousness of
>the drastic demonstration that i made [to modify and recompile debian
>packages]. of*course*  libsystemd0 should be dynamically loaded, and
>the userspace applications make the decision*at runtime*  as to what
>to do!

libsystemd0_is_  dynamically loaded, precisely so that userspace
applications can make the decision at runtime as to what to do.


What about dynamically linked?  Maybe Luke means dynamic linking 
(necessitating dynamic loading) instead?


--
Nate


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54e38cee.5040...@gmail.com

Re: how to remove libsystemd0 from a live-running debian desktop system

[claude juif]

2015-02-17 19:29 GMT+01:00 Nathan Schulte :

> Hi Andrew,
>
> On 02/17/2015 11:58 AM, Andrew Shadura wrote:
> > I find it really rude to send emails of about 300 lines of text in
> > total. Extremely rude.
>
> I for one am grateful Luke took the time to write the email he did.  I
> understand it was long and I believe that most won't even take the
> time to read it.  That is unfortunate, as I feel it is extremely
> level-headed and Luke actually wants to work at a resolution, which is
> much more than I can say for some of the other discussions I've been
> reading to try and keep up and stay informed.
>

I agree with this. This discussion is really valuable, and i see no flame
here. Just a discussion.

And that's what i find really wonderful with open source. You can speak
about things, say you are agree or not, and with every single part of
discussion, learn. Learning is the most important things in Linux world IMO.

I will use systemd because i like many of the improvements of it, (even if
i'm a system administrator lol)  but i want to know why some people don't
want to use it.

I learn a lot with that.



>
> The issue is that your reply does not contribute, and instead only
> detracts from the conversation.  I think everyone agrees that the more
> time we spend discussing the less time we spend developing a solution,
> but there is that saying about slowing down to speed up; I think it's
> applicable here.
>
> Please, next time, either disregard the email and keep silent, or make
> your reply relevant to the conversation.
>
> Understanding, addressing, and resolving these issues is *not a waste
> of time*.  If you feel that way, you are welcome to contribute in
> other ways.
>
> These are just my thoughts.
>
> --
> Nate
>

Re: how to remove libsystemd0 from a live-running debian desktop system

[Nathan Schulte]

Hi Andrew,

On 02/17/2015 11:58 AM, Andrew Shadura wrote:
> I find it really rude to send emails of about 300 lines of text in
> total. Extremely rude.

I for one am grateful Luke took the time to write the email he did.  I
understand it was long and I believe that most won't even take the
time to read it.  That is unfortunate, as I feel it is extremely
level-headed and Luke actually wants to work at a resolution, which is
much more than I can say for some of the other discussions I've been
reading to try and keep up and stay informed.

The issue is that your reply does not contribute, and instead only
detracts from the conversation.  I think everyone agrees that the more
time we spend discussing the less time we spend developing a solution,
but there is that saying about slowing down to speed up; I think it's
applicable here.

Please, next time, either disregard the email and keep silent, or make
your reply relevant to the conversation.

Understanding, addressing, and resolving these issues is *not a waste
of time*.  If you feel that way, you are welcome to contribute in
other ways.

These are just my thoughts.

--
Nate


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cao78khpno8u5pdm-m5u_tpjrgndcqjlsp++-0ed8nzdhiqo...@mail.gmail.com

Re: how to remove libsystemd0 from a live-running debian desktop system

[Luke Kenneth Casson Leighton]

adam, i apologise for not being in a position to reply in-thread: as
mentioned previously i tried (via gmane) but the entire discussion is
completely missing, and i forgot to ask people in the original post to
cc me if they would like an ongoing threaded reply.

i also notice that you removed debian-user, so for those people on
that list who (like me) were completely unaware of the fantastic work
that you've done, here is a link to the archives containing what you
wrote:

 https://lists.debian.org/debian-devel/2015/02/msg00189.html

all i can say is, HOORAY!  and thank you for doing properly what i
only hinted at was possible.  i wish i had known of what you've done,
even a few days ago.  i would have:

(a) not have had to mess up my system
(b) would not have written the slashdot report
(c) would not have heard from so many people who have put links to my
report onto their site
(d) not been in a position to further advocate your fantastic work (to them)

so... actually.. if you think about it, it's a good thing.

if you don't mind i'm going to contact several people who maintain web
sites and lists in order to have them add your work to them.

which should help answer the question you asked: your work - fantastic
as it is - was *impossible to find*.  it doesn't even remotely come up
on the radar of queries.  *nobody knows what you've achieved* and
that's something i would like to help correct.

now, exactly as you, i and russ point out, the next phase is to do
dynamic library loading.  i'm absolutely delighted to note that you
have a handle on this, already, and i see you make it clear that
you've thought it through already.

i plan to write directly to the systemd developers, taking at face
value the recent announcement that they listen to users.  is there
anything that you would recommend in particular that i include?

well done, and thank you for making my hacks completely irrelevant in
under 24 hours.

l.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/capweedwatrhrmtivzii369dk2wvx6kdrfodnzj7ek99mbht...@mail.gmail.com

Re: how to remove libsystemd0 from a live-running debian desktop system

[Luke Kenneth Casson Leighton]

On Tue, Feb 17, 2015 at 5:58 PM, Andrew Shadura  wrote:
> Hi,
>
> On 17 February 2015 at 18:20, claude juif  wrote:
>> Really rude answer. Really bad.
>
> I find it really rude to send emails of about 300 lines of text in
> total. Extremely rude.

 i did apologise in advance, and explained why i took the steps that i
did,.  if you are unable to accept that apology, i cannot help you
with that, andrew (as in: i recognise that i have no right to
interfere with your choice of mindset): it is your decision to choose
what to think and what to react to (positively or otherwise), and i
have to respect that.

 however as this is a public forum for discussing debian, and there
are thousands of people reading this and many more in the future,
apart from apologising for taking up so much time in distractions of
this kind i am not going to get involved further into discussions of
ettiquette, if that's ok.

l.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAPweEDxKaorP=84ztkzrakptawngboy4_9ry7hg_7jwhnss...@mail.gmail.com

Re: how to remove libsystemd0 from a live-running debian desktop system

[Marc Haber]

On Mon, 16 Feb 2015 22:31:19 +0100, m...@linux.it (Marco d'Itri) wrote:
>As usual, the systemd critics are just misinformed. This comforts me. 
>because it means that their views can be easily ignored.

And as usual, you don't make any effort to change the misinformation.
Otoh, most systemd documentation lacks objectivity.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1ynmur-0003j2...@swivel.zugschlus.de

Re: how to remove libsystemd0 from a live-running debian desktop system

[Andrew Shadura]

Hi,

On 17 February 2015 at 18:20, claude juif  wrote:
> Really rude answer. Really bad.

I find it really rude to send emails of about 300 lines of text in
total. Extremely rude.

-- 
Cheers,
  Andrew


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CACujMDMNn1MbB=rVusoxLH_X-yBAt51u6LnhC9XE55z6k=u...@mail.gmail.com

Re: how to remove libsystemd0 from a live-running debian desktop system

[Nikolaus Rath]

On Feb 17 2015, Alastair McKinstry  wrote:
> On 17/02/2015 10:55, Vincent Bernat wrote:
>>  ❦ 17 février 2015 10:18 GMT, Alastair McKinstry 
>>  :
>>
> The breakage of compatibility of existing systems (e.g. with /usr on a
> separate partition) has left a sour taste. I spent  a weekend repairing
 systemd introduces no such breakage. Also, /usr on a separate partition 
 was partially broken even before systemd.

>>> My system broke. It was fine, I did an upgrade -> jessie. It broke
>>> because of systemd and the fact I had /usr on a separate partition.
>> And no initrd? Mounting /usr is the job of the initrd.
>
> Examination after the fact showed that if I'd had the correct packages
> installed, it would have worked.
> So from a Debian perspective this was 'notabug'.
> (modules that were not needed day-to-day had been deleted by hand to
> make space on /.
> A broken initrd was then built during dist-upgrade. My fault).
>
> But this didn't change the user experience: a system broke badly during
> systemd upgrade due to local changes.

Aeh, what? What you describe above is about as much related to a systemd
upgrade is it is to an ntfs-3g upgrade. Anything that triggers an initrd
rebuild would have had this effect. Blaming systemd is absurd.

Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87twykfnpq@thinkpad.rath.org

Re: how to remove libsystemd0 from a live-running debian desktop system

[The Wanderer]

On 02/17/2015 at 11:28 AM, Luke Kenneth Casson Leighton wrote:

> so, marco, you wrote:
> 
>> Again, you clearly do not understand well how systemd works.
> 
> marco: understanding or otherwise how systemd works is not the
> point: the point is that there has been a unilateral decision across 
> virtually every single GNU/Linux distro to abandon and remove *any* 
> alternative to having libsystemd0 installed.  historical precedent
> in the software industry and beyond tells us that placing so much
> power and trust in a single system and a single group should be
> ringing alarm bells so loudly in your head that you should wake up
> deaf after having first passed out with dizziness! :)
> 
> so could i ask you, as i really genuinely don't understand, why is
> it that the lack of choice here *doesn't* bother you?  i'm not asking
> for a technical review or a technically-based argument as to "why 
> libsystemd0 is better" - that has been debated many many times and
> is entirely moot.  i'm asking "why does *only* having libsystemd0 as
> the sole exclusive startup method, removal of which prevents and
> prohibits the use of a whopping FIFTEEN PERCENT of the available
> debian software base, and where that exclusive exclusionary process
> is being rapidly duplicated across virtually every single GNU/Linux
> distribution that we know; why does that *not* make you pause for
> thought that there might be something desperately and very badly
> wrong?"

libsystemd0 is not a startup method, or an init system. It's a shared
library which permits detection of whether systemd (and the
functionality which it provides) is present.

There's certainly an undesirable ambiguity about what is meant by any
given use of the term "systemd", since it can refer equally to the
/lib/systemd/systemd binary, to the PID1 process (which is exactly the
same as the previous thing AFAIK, except running as PID1 rather than as
a more ordinary system citizen), to more-or-less the entire collection
of software which is provided by the systemd project, or to the systemd
project itself. But as far as I'm aware, this is the first time I've
ever seen anyone refer to the PID1 process or the entire collection of
software as 'libsystemd0'.

You only harm your case by misusing and confusing terminology in that
way.

> russ writes:
> 
>> Alas, the resulting distribution is still hopelessly compromised by
>> the NSA, who might be even worse than Lennart Poettering.  To see
>> how deep the tendrils of US government infiltration go, just try
>> removing libselinux1, and marvel at how much concerted malevolent
>> effort has gone into destroying your freedom.
> 
> and:
> 
>> Or, alternately, you could research how and why one would use
>> shared libraries in a binary distribution to support optional
>> features.  But that's boring, prosaic, and nowhere near as much fun
>> to write about.
> 
> ahhh russ - good maaan :)  here we have a hint of a possible
> solution, one where i'm going to need to speak to the systemd team
> for a feature request / design decision (and can i ask you and anyone
> else to do the same?).  you've hit on what i believe is *the* perfect
> and acceptable decision that is hinted at by the ridiculousness of
> the drastic demonstration that i made [to modify and recompile debian
> packages]. of *course* libsystemd0 should be dynamically loaded, and
> the userspace applications make the decision *at runtime* as to what
> to do!

libsystemd0 _is_ dynamically loaded, precisely so that userspace
applications can make the decision at runtime as to what to do.

systemd (in either of the first two senses, above) is not, but unless
I'm greatly mistaken, making that runtime detection possible is most if
not all of the entire reason why libsystemd0 exists.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: how to remove libsystemd0 from a live-running debian desktop system

[Luke Kenneth Casson Leighton]

On Tue, Feb 17, 2015 at 5:20 PM, claude juif  wrote:
>
>
> 2015-02-17 17:55 GMT+01:00 Andrew Shadura :
>>
>> Hi Luke,
>>
>> On 17 February 2015 at 17:28, Luke Kenneth Casson Leighton
>>  wrote:
>> > <265 lines of text and counting snipped>
>>
>> In short, this is TL;DR. We've all got better things to waste our time
>> on. Please go away. Nobody's interested in this any longer regardless
>> of their position on systemd.
>>
>> Thanks.
>
>
> Hi,
>
> Really rude answer. Really bad.

 thanks for pointing that out, claude - it helps that it was someone
else who pointed out that being uncivil by asking a *person* to go
away doesn't make the *problem* go away.

 andrew: i will go away only when i am satisified that the problem
which i believe it is my duty and responsibility to help highlight and
fix has, in fact gone away.

 if you feel that this is sufficiently beyond your psyche's limits,
there are a number of ways in which you may deal with that, but
*demanding* of people that they violate their principles, as well as
inconveniencing many other people and increasing _their_ stress levels
by voicing such demands... can you see how that that really will not
work out very well, for everyone involved, including yourself?

 short answer: no, i will not accede to your unreasonable demand.  i
have the right to speak up, and, just to make it clear: like that
famous person said, which i find myself quoting within a couple of
hours for completely  different reasons, "i do not agree with you, but
i will defend your right to say so".

 so thank you for making it clear that you find this difficult to cope
with, but please do take a relaxing holiday or something, ok? :)

 anyway, in other news, i'm delighted to have been made aware (very
recently) of the work by adam borowski, which i have to say is
completely unknown and underappreciated at this point.  links are
here:

 http://forums.debian.net/viewtopic.php?f=20&t=119836

 it would appear that one person has managed to achieve what the
devuan team are endeavouring to duplicate, and what my report has only
begun to scratch the surface on.  i find this to be incredibly funny.

 *but*... we are *not done yet*.  the work by adam is amazing and
everything that i was hoping would be done as an interim measure, so
adam THANK YOU, you have made it possible for the average end-user and
sysadmin to continue to manage their machines in a convenient way
*and* still make the choice to not have libsystemd0 present, and
that's just... words fail me to express my gratitude.

 *but*... the next phase is to tackle upstream and to pursue the
design concept advocated by russ: dynamic loading.  there really
should be no need to use what adam's done (or what devuan want).  it
*really should* be possible to install (or remove) a few packages that
are *part of debian*, and have libsystemd0 enabled or disabled *at
will*.  even with editing an /etc/ config file.

 that this is not even possible *is* why i will not stop - andrew -
until it is.  have i made myself clear?

l.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAPweEDxC+vvKuUd5sORghK1FX1NPhw-n97zHZsT21RCgkujM=q...@mail.gmail.com

Re: how to remove libsystemd0 from a live-running debian desktop system

[claude juif]

2015-02-17 17:55 GMT+01:00 Andrew Shadura :

> Hi Luke,
>
> On 17 February 2015 at 17:28, Luke Kenneth Casson Leighton
>  wrote:
> > <265 lines of text and counting snipped>
>
> In short, this is TL;DR. We've all got better things to waste our time
> on. Please go away. Nobody's interested in this any longer regardless
> of their position on systemd.
>
> Thanks.
>

Hi,

Really rude answer. Really bad.


>
> --
> Cheers,
>   Andrew
>
>
> --
> To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive:
> https://lists.debian.org/CACujMDNDBe31Crs9uRSt9Bph=nrvgfbtx9ha+3ckv3wurq6...@mail.gmail.com
>
>

Re: how to remove libsystemd0 from a live-running debian desktop system

[Eduard Bloch]

Hallo,
* Luke Kenneth Casson Leighton [Tue, Feb 17 2015, 04:28:04PM]:
> so to summarise:
> 
> * the use of libselinux1 is dormant (i.e. whilst you can't remove it
> without inconvenience, its use is entirely optional, right from the
> kernel level)
> * its development and documentation is rational and well-researched
> * the timeline behind its introduction was done in a respectful and
> reasonable way

> now let's compare that to the situation that we find ourselves in with
> libsystemd0:

Talk only about you, please. The "yourselves" of yours seems to lack
basic research skills.

> * the use of libsystemd0 is MANDATORY and EXCLUSIONARY (everywhere
> except slackware and FreeBSD)

Wrong. It is also dormant, except for a little function that
applications call.

> * its development is a moving target and the documentation of the
> roadmap is informal and sparse.

And that little piece of code had just six commits according to:
git log ./src/libsystemd/sd-daemon/sd-daemon.c | grep commit
and most of them are minor changes.

That's a HELL OF MOVING TARGET, yeah.  Now, enjoy the feel of being my
personal hero, take a cookie, STFU and go away. Thanks.

Deleted the rest of unfunded crap.

Regards,
Eduard.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150217170822.ga7...@rotes76.wohnheim.uni-kl.de

Re: how to remove libsystemd0 from a live-running debian desktop system

[Andrew Shadura]

Hi Luke,

On 17 February 2015 at 17:28, Luke Kenneth Casson Leighton
 wrote:
> <265 lines of text and counting snipped>

In short, this is TL;DR. We've all got better things to waste our time
on. Please go away. Nobody's interested in this any longer regardless
of their position on systemd.

Thanks.

-- 
Cheers,
  Andrew


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CACujMDNDBe31Crs9uRSt9Bph=nrvgfbtx9ha+3ckv3wurq6...@mail.gmail.com

Re: how to remove libsystemd0 from a live-running debian desktop system

[Luke Kenneth Casson Leighton]

ok, so there's been quite a discussion, both on slashdot, where
amazingly the comments that filtered to the top were insightful and
respectful, and also here on debian-devel and debian-users.  as i
normally use gmane to reply (and maintain and respect threads) but
this discussion is not *on* gmane, i apologise for having to write a
summary-style follow-up: if people would like me to reply (thank you
christian) please cc me in future, but (see last paragraph) i think
the software libre community's interests are best served if i wait for
replies to accumulate for a few days.

after thinking about this yesterday, a random sentence popped into my
head, which i believe is very appropriate:

"i disagree with what you are saying, but i will defend your right
to say it".

i believe it was someone famous who wrote that, and it applies to this
situation because this really isn't about the technical merits of the
available software: solutions will come in time (and already are:
eudev, mdev, uselessd and many more).  the reason why i've joined this
debate is because i feel that closing doors on choice in ways that
force people to have to make extremely disruptive and risky decisions
that could adversely affect their livelihoods - i have a *really* bad
feeling about that, and i cannot sit by and let it happen without
speaking up.

in the past two days i've seen a lot of people on this list make it
clear (by saying for example "you have the source, go modify it") that
they do not truly appreciate the responsibility and duty of care that
they have.  in saying that i can say that *i know* how you feel: i've
been the leader of many software libre projects where people would
expect me to feed them answers for no financial reward - and all those
other nuances that we frequently encounter.  but i learned in the past
few years that even if you are not being paid, you *still* have a duty
to those people less intelligent or with less time or less money than
you.  we're *serving others* with our skill, time and intelligence.
it's a really awkward and delicate situation, i know, but answering
"go away and modify the source yourself" is to do both yourself and
the recipient of that answer a very strong disservice.

anyway - down to it.

so, marco, you wrote:

> Again, you clearly do not understand well how systemd works.

marco: understanding or otherwise how systemd works is not the point:
the point is that there has been a unilateral decision across
virtually every single GNU/Linux distro to abandon and remove *any*
alternative to having libsystemd0 installed.  historical precedent in
the software industry and beyond tells us that placing so much power
and trust in a single system and a single group should be ringing
alarm bells so loudly in your head that you should wake up deaf after
having first passed out with dizziness! :)

so could i ask you, as i really genuinely don't understand, why is it
that the lack of choice here *doesn't* bother you?  i'm not asking for
a technical review or a technically-based argument as to "why
libsystemd0 is better" - that has been debated many many times and is
entirely moot.  i'm asking "why does *only* having libsystemd0 as the
sole exclusive startup method, removal of which prevents and prohibits
the use of a whopping FIFTEEN PERCENT of the available debian software
base, and where that exclusive exclusionary process is being rapidly
duplicated across virtually every single GNU/Linux distribution that
we know; why does that *not* make you pause for thought that there
might be something desperately and very badly wrong?"

ric writes, amongst other things:

> You are completely free to fork or go your own direction,

indeed we are, and in fact one person mentions further in the thread
so far that they did exactly that.  they also outline quite how much
work it is.  on the slashdot discussion, someone pointed out that it
was really unconscionable that people have to go to such extreme
lengths.  GNU/Linux distros should be a place where people can make
happy and convenient choices, not extreme decisions!  the extreme
absurd version of what you suggest is to do what very very few people
in the world have ever done (one of them being richard lightman, an
amazingly intelligent and reclusive individual), namely to create an
*entire* linux distribution - on their own - from source.  i take it
you can see, from that example, quite how much of a disservice it is
to say what you said, ric?

no, the very fact that this *doesn't go away* - that discussions about
libsystemd0 are *continuous and ongoing*, should tell you that there
is something very, very badly wrong with what's going on.  and that's
what i want to get to the bottom of.  like... *properly* understand.

the second thing, ric, is that i have to point out, respectfully, that
there are signs that you didn't read the slashdot article summary, nor
my report, as shown here:

> But, to raise comparisons to MicroSoft is very much out of line.

t

Re: how to remove libsystemd0 from a live-running debian desktop system

[Vincent Bernat]

 ❦ 17 février 2015 12:57 GMT, Alastair McKinstry  :

> The breakage of compatibility of existing systems (e.g. with /usr on a
> separate partition) has left a sour taste. I spent  a weekend repairing
 systemd introduces no such breakage. Also, /usr on a separate partition 
 was partially broken even before systemd.

>>> My system broke. It was fine, I did an upgrade -> jessie. It broke
>>> because of systemd and the fact I had /usr on a separate partition.
>> And no initrd? Mounting /usr is the job of the initrd.
>
> Examination after the fact showed that if I'd had the correct packages
> installed, it would have worked.  So from a Debian perspective this
> was 'notabug'.  (modules that were not needed day-to-day had been
> deleted by hand to make space on /.  A broken initrd was then built
> during dist-upgrade. My fault).
>
> But this didn't change the user experience: a system broke badly during
> systemd upgrade due to local changes.

There were other similar breakage totally unrelated to systemd. For
example:
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=720593

In the meantime, moving libraries from /usr/lib to /lib or adding
symlinks was considered unproductive and the problem was fixed by
mounting /usr in the initrd:
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=652459
-- 
Use variable names that mean something.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: how to remove libsystemd0 from a live-running debian desktop system

[Matthias Klumpp]

2015-02-17 13:57 GMT+01:00 Alastair McKinstry :
> [...]
>
> Examination after the fact showed that if I'd had the correct packages
> installed, it would have worked.
> So from a Debian perspective this was 'notabug'.
> (modules that were not needed day-to-day had been deleted by hand to
> make space on /.
> A broken initrd was then built during dist-upgrade. My fault).
>
> But this didn't change the user experience: a system broke badly during
> systemd upgrade due to local changes. A blaming exercise of "your own
> fault for doing X" and "you should have known Y"  doesn't change the
> fact that systemd changes are so comprehensive and all-invasive that
> systemd works well for two groups:

With that argumentation, we could not make any changes to Debian
anymore, because users could do any arbitrary change which could break
upgrade, e.g. removing stuff from /sbin manually etc.
If you perform invasive changes on your system, and then do a Debian
upgrade, you should be able to handle the upgrade and take additional
care to make the upgrade work properly with your local changes.

> either 'simple users' who make no changes to the standard
> configurations, or full systemd developers who know the detailed changes
> that it makes in all areas and the consequences for their computers.
>
> Users who make a few local changes to their system, not simple
> configuration changes but code / scripting
> changes of their own, now live in trepidation to what systemd will do.

That's not systemd-specific. If you make bigger invasive changes, I
would expect you to *know* what you are doing and be able to handle
the consequences of the changes. There is no way we can account for
random changes in Debian packaging.

> Its no longer enough to run a "standard Debian + a unique firewall whose
> design I made and know well"
> now live in trepidation, not sure what systemd changes will come next.

Everything is changing constantly :-) And systemd does have migration
paths in case stuff is changed. But again, this particular "I don't
know what change will be next" issue is not specific to systemd -
Debian itself might introduce new default packages at any time, or
perform large transitions like the multiarch-transition, which break
your assumptions on how stuff usually was (in that example, libraries
suddently being installed into /usr/lib/).

> Most components in Linux are small, self-contained, concisely
> documented. Not so for systemd.

That's a false assumption. Systemd consists of small, well-documented
tools which happen to be shipped in one tarball and are designed to
work together and work together well.
Just take a look at the contants of the "systemd" Debian package ;-)

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAKNHny8PoSv00nbqHbX0jNpob2tOUOTb80AYrYr=lyuusfp...@mail.gmail.com

Re: how to remove libsystemd0 from a live-running debian desktop system

[Ben Hutchings]

On Tue, 2015-02-17 at 12:57 +, Alastair McKinstry wrote:
> On 17/02/2015 10:55, Vincent Bernat wrote:
> >  ❦ 17 février 2015 10:18 GMT, Alastair McKinstry 
> >  :
> >
>  The breakage of compatibility of existing systems (e.g. with /usr on a
>  separate partition) has left a sour taste. I spent  a weekend repairing
> >>> systemd introduces no such breakage. Also, /usr on a separate partition 
> >>> was partially broken even before systemd.
> >>>
> >> My system broke. It was fine, I did an upgrade -> jessie. It broke
> >> because of systemd and the fact I had /usr on a separate partition.
> > And no initrd? Mounting /usr is the job of the initrd.
> 
> Examination after the fact showed that if I'd had the correct packages
> installed, it would have worked.
> So from a Debian perspective this was 'notabug'.
> (modules that were not needed day-to-day had been deleted by hand to
  ^^^ 
> make space on /.
> A broken initrd was then built during dist-upgrade. My fault).
[...]

Yes, exactly.  Laying any blame on systemd for this is completely
unreasonable.

(It might be more reasonable to blame initramfs-tools if it didn't give
you any warnings.)

Ben.

-- 
Ben Hutchings
Never attribute to conspiracy what can adequately be explained by stupidity.


signature.asc
Description: This is a digitally signed message part

Re: how to remove libsystemd0 from a live-running debian desktop system

[Alastair McKinstry]

On 17/02/2015 10:55, Vincent Bernat wrote:
>  ❦ 17 février 2015 10:18 GMT, Alastair McKinstry 
>  :
>
 The breakage of compatibility of existing systems (e.g. with /usr on a
 separate partition) has left a sour taste. I spent  a weekend repairing
>>> systemd introduces no such breakage. Also, /usr on a separate partition 
>>> was partially broken even before systemd.
>>>
>> My system broke. It was fine, I did an upgrade -> jessie. It broke
>> because of systemd and the fact I had /usr on a separate partition.
> And no initrd? Mounting /usr is the job of the initrd.

Examination after the fact showed that if I'd had the correct packages
installed, it would have worked.
So from a Debian perspective this was 'notabug'.
(modules that were not needed day-to-day had been deleted by hand to
make space on /.
A broken initrd was then built during dist-upgrade. My fault).

But this didn't change the user experience: a system broke badly during
systemd upgrade due to local changes. A blaming exercise of "your own
fault for doing X" and "you should have known Y"  doesn't change the
fact that systemd changes are so comprehensive and all-invasive that
systemd works well for two groups:
either 'simple users' who make no changes to the standard
configurations, or full systemd developers who know the detailed changes
that it makes in all areas and the consequences for their computers.

Users who make a few local changes to their system, not simple
configuration changes but code / scripting
changes of their own, now live in trepidation to what systemd will do.
Its no longer enough to run a "standard Debian + a unique firewall whose
design I made and know well"
now live in trepidation, not sure what systemd changes will come next.

Most components in Linux are small, self-contained, concisely
documented. Not so for systemd.

regards
Alastair

-- 
Alastair McKinstry, , , 
https://diaspora.sceal.ie/u/amckinstry
Misentropy: doubting that the Universe is becoming more disordered. 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54e33ab3.8010...@sceal.ie

Re: how to remove libsystemd0 from a live-running debian desktop system

[Vincent Bernat]

 ❦ 17 février 2015 10:18 GMT, Alastair McKinstry  :

>>> The breakage of compatibility of existing systems (e.g. with /usr on a
>>> separate partition) has left a sour taste. I spent  a weekend repairing
>> systemd introduces no such breakage. Also, /usr on a separate partition 
>> was partially broken even before systemd.
>>
> My system broke. It was fine, I did an upgrade -> jessie. It broke
> because of systemd and the fact I had /usr on a separate partition.

And no initrd? Mounting /usr is the job of the initrd.
-- 
ROMEO:  Courage, man; the hurt cannot be much.
MERCUTIO:   No, 'tis not so deep as a well, nor so wide
as a church-door; but 'tis enough, 'twill serve.


signature.asc
Description: PGP signature

Re: how to remove libsystemd0 from a live-running debian desktop system

[Alastair McKinstry]

On 16/02/2015 21:31, Marco d'Itri wrote:
> On Feb 16, Alastair McKinstry  wrote:
>
>> The breakage of compatibility of existing systems (e.g. with /usr on a
>> separate partition) has left a sour taste. I spent  a weekend repairing
> systemd introduces no such breakage. Also, /usr on a separate partition 
> was partially broken even before systemd.
>
My system broke. It was fine, I did an upgrade -> jessie. It broke
because of systemd and the fact I had /usr on a separate partition.
Its an old system. Much repair later showed I was lacking some modules
due to a lack of space at one time. So ok, not a "proper" bug, my fault,
no bug logged. However I did spend the weekend rebooting, hacking, to
try and get it fixed.

But the fact that I did not end up needing to submit bugs against
wheezy/jessie hides the fact that things broke. There are lots of
'slightly non-standard' systems out there that have minor local changes
that the admin can maintain. As systemd touches so much, it will break
lots of these corner cases
>> I have real problems with this lack of modularity.
> Again, you clearly do not understand well how systemd works.
Yes, and you've failed to see how this is not just my problem, its
Debians problem.

Its fairly typical for a developer to have in-depth knowledge in the
corner where they are working, but a mild working knowledge of other
areas, where they don't need to keep up with the latest developments in
the field. E.g. I don't pay attention to the latest developments in
bluetooth. It just works (or doesn't), I don't care.

But systemd now touches everything it seems. For example networking:
http://www.phoronix.com/scan.php?page=news_item&px=systemd-networkd-IP-Forward

I have local, special changes to networks and firewalls. Am I supposed
to keep intimately involved in systemd developments in this area, to
make sure my systems will stay working?
I have no desire to do so, and none to explain what unique changes I
want to maintain on my home systems and make sure they work. I just want
the code base involved to be small enough that I can follow and change it.

When we voted on default pid0, I was not particularly concerned, but
this is definitely not what I signed up for.

> As usual, the systemd critics are just misinformed. This comforts me. 
> because it means that their views can be easily ignored.
>
!

-- 
Alastair McKinstry, , , 
https://diaspora.sceal.ie/u/amckinstry
Misentropy: doubting that the Universe is becoming more disordered. 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54e31568.1080...@sceal.ie

Re: how to remove libsystemd0 from a live-running debian desktop system

[Riley Baird]

> > But dictatorially coming in and demanding that volunteers join you in
> > riding your hobby horse? Please leave.
> 
> I did not see any dictatorial demands in his message, he gave the story
> on how to get rid of systemd _within_ Debian, nothing else.

True, but it was bait for another systemd debate, which unfortunately seems to 
have succeeded. (There would be nothing wrong with posting such a guide 
normally, but generally guides shouldn't be mixed with several paragraphs of 
politics.)


pgpyT6S5E1KB8.pgp
Description: PGP signature

Re: how to remove libsystemd0 from a live-running debian desktop system

[Svante Signell]

On Mon, 2015-02-16 at 23:45 +0100, Mart van de Wege wrote:
> Luke Kenneth Casson Leighton  writes:
> 
> > On Mon, Feb 16, 2015 at 11:42 AM, Christian Seiler  
> > wrote:
> >> Am 16.02.2015 um 02:54 schrieb Luke Kenneth Casson Leighton:
> >>>
> >>> http://lkcl.net/reports/removing_systemd_from_debian/
> >>
> >>
> >> It's funny that when Wheezy (not Jessie!) came out, nobody complained
> >> that libsystemd-login0 (which is now part of libsystemd0) was as a
> >> dependency of dbus, so it is probably already installed on most desktop
> >> systems running current Debian stable.

The amount chew aimed for with today's systemd was not known at that
time.

> >  my assessment is that it's that total lack of choice that is causing
> > people to get so upset.
>
> And you have a choice: stick with old software, or (help) code a
> replacement yourself. That has always been the Free Software way.

Replacement software is already being developed, no problem! Don't say
that everybody complains, many people see this a challenge to make a
change from ?mainstream?.

> But dictatorially coming in and demanding that volunteers join you in
> riding your hobby horse? Please leave.

I did not see any dictatorial demands in his message, he gave the story
on how to get rid of systemd _within_ Debian, nothing else.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1424163558.12329.32.ca...@gmail.com

Re: how to remove libsystemd0 from a live-running debian desktop system

[Mart van de Wege]

Luke Kenneth Casson Leighton  writes:

> On Mon, Feb 16, 2015 at 11:42 AM, Christian Seiler  wrote:
>> Am 16.02.2015 um 02:54 schrieb Luke Kenneth Casson Leighton:
>>>
>>> http://lkcl.net/reports/removing_systemd_from_debian/
>>
>>
>> It's funny that when Wheezy (not Jessie!) came out, nobody complained
>> that libsystemd-login0 (which is now part of libsystemd0) was as a
>> dependency of dbus, so it is probably already installed on most desktop
>> systems running current Debian stable.
>
>  i'll hazard a guess that it's because they had no idea that, in the
> very near future, all the major desktop developers and all the major
> distros would make the unilateral decision to hard-code the
> *exclusive* use of systemd (or parts of it).

Really? Now why would such a disparate group of programmers want to use
a particular piece of software? Maybe because it solves some of their
problems and they don't have to reinvent the wheel?

You don't hear me whining that almost all C++ software these days pulls
in libboost.
>
>  my assessment is that it's that total lack of choice that is causing
> people to get so upset.

Funny, I don't see those same people upset that they have only one
choice for authentication (PAM). Or that selinux is installed by default
on almost all distros.

And you have a choice: stick with old software, or (help) code a
replacement yourself. That has always been the Free Software way.

But dictatorially coming in and demanding that volunteers join you in
riding your hobby horse? Please leave.

Mart

-- 
"We will need a longer wall when the revolution comes."
--- AJS, quoting an uncertain source.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/86zj8d79wo@gaheris.avalon.lan

Re: how to remove libsystemd0 from a live-running debian desktop system

[Marco d'Itri]

On Feb 16, Alastair McKinstry  wrote:

> The breakage of compatibility of existing systems (e.g. with /usr on a
> separate partition) has left a sour taste. I spent  a weekend repairing
systemd introduces no such breakage. Also, /usr on a separate partition 
was partially broken even before systemd.

> I have real problems with this lack of modularity.
Again, you clearly do not understand well how systemd works.

As usual, the systemd critics are just misinformed. This comforts me. 
because it means that their views can be easily ignored.

-- 
ciao,
Marco


pgpbGfP3TnwTe.pgp
Description: PGP signature

Re: how to remove libsystemd0 from a live-running debian desktop system

[Eduard Bloch]

Hallo,
* Lisi Reisz [Mon, Feb 16 2015, 11:42:14AM]:
> On Monday 16 February 2015 08:09:19 Marco d'Itri wrote:
> > > to debian-users: you don't have complete choice (yet), but i have
> > > demonstrated with a few hours work that there is a way to run
> > > (certain) desktop environments without requiring libsystemd0 or any of
> > > its dependencies, and after a little investigation there do appear to
> > > be people working hard to give you your right to choose what software
> > > to run *without* having to abandon debian.
> >
> > I strongly recommend that the people who cannot live with libsystemd0
> > installed on their systems leave Debian,
> 
> Oh, yes, please!  Please.  Please.  You have lots of choice.  There are lots 
> of distros and you can fork (devuan).  But leave us in peace!  It has been 
> lovely on this list without you lot.

+1, please!

(And if you still want to start a crusade against system libraries,
please try practicing first with more famous targets like libselinux1 or
even libpthread... nobody needs this dependency hell, right?)

Regards,
Eduard.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150216185543.ga18...@rotes76.wohnheim.uni-kl.de

Re: how to remove libsystemd0 from a live-running debian desktop system

[Cameron Norman]

On Mon, Feb 16, 2015 at 8:14 AM, Matthias Klumpp  wrote:
> 2015-02-16 16:26 GMT+01:00 Alastair McKinstry :
>> [...]
>> An an example, i've been a long-term linux developer, DD; i've developed
>> and promoted Linux not just on the desktop but both in embedded systems
>> and in HPC systems. In all these I've been comfortable that I've been
>> able to adapt Linux, reconfigure, do what was needed to get it going on
>> any size of device, and get my changes either accepted upstream,
>> maintain them locally in my organisation or both. With systemd I don't
>> think I could do that, and thats very disempowering.
>
> Why do you think you can't do that anymore? Systemd is used on
> embedded devices, reaching from the Jolla smartphone to things like
> the Vocore or Raspberry Pi.

Kind of off topic, but are the RPi and Jolla embedded systems? The
weakest Raspberry Pi has almost ten times as much RAM as the vocore.
And both have discrete GPUs. I don't know, it seems like a stretch to
call those two embedded.

--
Cameron Noramn


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CALZWFRK4WbE1m-LT=0478+rd4_rwaa3gnpqh6q59uvkdaf2...@mail.gmail.com

Re: how to remove libsystemd0 from a live-running debian desktop system

[Alastair McKinstry]

On 16/02/2015 16:14, Matthias Klumpp wrote:
> 2015-02-16 16:26 GMT+01:00 Alastair McKinstry :
>> [...]
>> An an example, i've been a long-term linux developer, DD; i've developed
>> and promoted Linux not just on the desktop but both in embedded systems
>> and in HPC systems. In all these I've been comfortable that I've been
>> able to adapt Linux, reconfigure, do what was needed to get it going on
>> any size of device, and get my changes either accepted upstream,
>> maintain them locally in my organisation or both. With systemd I don't
>> think I could do that, and thats very disempowering.
> Why do you think you can't do that anymore? Systemd is used on
> embedded devices, reaching from the Jolla smartphone to things like
> the Vocore or Raspberry Pi.
> Getting changes accepted upstream is also not a hard thing, systemd is
> not different from any other upstream we have. Suure, there will be
> patches which are not in-scope, some will receive criticism, need to
> be adapted and rewritten, but that happens basically everywhere.
> For projects using systemd features, adapting them to do what you want
> also shouldn't be a problem, and the systemd unit files (from the
> initsystem part of it) can easily be changed and overridden to serve
> custom needs.
> So, do you have concrete bad experience? If so, working on that and
> fixing the associated bugs would be a useful thing to do.
>
The breakage of compatibility of existing systems (e.g. with /usr on a
separate partition) has left a sour taste. I spent  a weekend repairing
an upgrade after that one. My expectations of getting 'interesting' new
configurations such as Debian for Drones(TM) accepted are not high.

Compared to existing systems, systemd is tightly integrated by design.
Dropping components, customising components becomes much harder. If I
develop a new type of networking, for example, it might be 2-3 years
before my code is accepted into mainstream kernels/ setups. In the
meantime, i'm maintaining a fork myself.
With the current modular design the amount of code I need to maintain 
is small. In a systemd-type world, I have to learn to integrate it with
systemd, and maintain a fork of systemd.

I have real problems with this lack of modularity.

Alastair

>> [...]
> Cheers,
> Matthias
>
> P.S: Does this really have to be crossposted to -user and -devel?
>
>

-- 
Alastair McKinstry, , , 
https://diaspora.sceal.ie/u/amckinstry
Misentropy: doubting that the Universe is becoming more disordered. 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54e21e8f.4010...@sceal.ie

Re: how to remove libsystemd0 from a live-running debian desktop system

[Matthias Klumpp]

2015-02-16 16:26 GMT+01:00 Alastair McKinstry :
> [...]
> An an example, i've been a long-term linux developer, DD; i've developed
> and promoted Linux not just on the desktop but both in embedded systems
> and in HPC systems. In all these I've been comfortable that I've been
> able to adapt Linux, reconfigure, do what was needed to get it going on
> any size of device, and get my changes either accepted upstream,
> maintain them locally in my organisation or both. With systemd I don't
> think I could do that, and thats very disempowering.

Why do you think you can't do that anymore? Systemd is used on
embedded devices, reaching from the Jolla smartphone to things like
the Vocore or Raspberry Pi.
Getting changes accepted upstream is also not a hard thing, systemd is
not different from any other upstream we have. Suure, there will be
patches which are not in-scope, some will receive criticism, need to
be adapted and rewritten, but that happens basically everywhere.
For projects using systemd features, adapting them to do what you want
also shouldn't be a problem, and the systemd unit files (from the
initsystem part of it) can easily be changed and overridden to serve
custom needs.
So, do you have concrete bad experience? If so, working on that and
fixing the associated bugs would be a useful thing to do.

> [...]

Cheers,
Matthias

P.S: Does this really have to be crossposted to -user and -devel?


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caknhny9+39n7vcxqmzsfr_fek9ydom3p2hj10gsr7dabed-...@mail.gmail.com

Re: how to remove libsystemd0 from a live-running debian desktop system

[Christian Kastner]

On 2015-02-16 16:26, Alastair McKinstry wrote:
> On 16/02/2015 14:41, Christian Kastner wrote:
>> I'll hazard another guess, namely that the great vast majority of users
>> simply do not care. I'd be surprised if most users even know what an
>> init system does, much less what the differences between sysvinit /
>> systemd / upstart / etc are. [*]
> But the developers _do_ care, and that matters.

Yes, some -- probably even many! -- developers do care. And many of them
actively contribute to a solution, be it with constructive criticism, or
sharing insights, or providing patches. And I truly, deeply value that.

However, the certain group of people my complaint was addressed to seem
to contribute only drama and discord.

> See John Goertzens insightful blog post:
> 
> http://changelog.complete.org/archives/9304-reactions-to-has-modern-linux-lost-its-way-and-the-value-of-simplicity
> 
> An an example, i've been a long-term linux developer, DD; i've developed
> and promoted Linux not just on the desktop but both in embedded systems
> and in HPC systems. In all these I've been comfortable that I've been
> able to adapt Linux, reconfigure, do what was needed to get it going on
> any size of device, and get my changes either accepted upstream,
> maintain them locally in my organisation or both. With systemd I don't
> think I could do that, and thats very disempowering.
> 
> Do I really need to point out that if we lose developers, then the users
> lose too?


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/f493006db2902ca503093d87e6c7e...@kvr.at

Re: how to remove libsystemd0 from a live-running debian desktop system

[Alastair McKinstry]

On 16/02/2015 14:41, Christian Kastner wrote:
> On 2015-02-16 13:47, Luke Kenneth Casson Leighton wrote:
>> On Mon, Feb 16, 2015 at 11:42 AM, Christian Seiler  
>> wrote:
>>> Am 16.02.2015 um 02:54 schrieb Luke Kenneth Casson Leighton:
 http://lkcl.net/reports/removing_systemd_from_debian/
>>>
>>> It's funny that when Wheezy (not Jessie!) came out, nobody complained
>>> that libsystemd-login0 (which is now part of libsystemd0) was as a
>>> dependency of dbus, so it is probably already installed on most desktop
>>> systems running current Debian stable.
>>  i'll hazard a guess that it's because they had no idea that, in the
>> very near future, all the major desktop developers and all the major
>> distros would make the unilateral decision to hard-code the
>> *exclusive* use of systemd (or parts of it).
> I'll hazard another guess, namely that the great vast majority of users
> simply do not care. I'd be surprised if most users even know what an
> init system does, much less what the differences between sysvinit /
> systemd / upstart / etc are. [*]
But the developers _do_ care, and that matters.

See John Goertzens insightful blog post:

http://changelog.complete.org/archives/9304-reactions-to-has-modern-linux-lost-its-way-and-the-value-of-simplicity

An an example, i've been a long-term linux developer, DD; i've developed
and promoted Linux not just on the desktop but both in embedded systems
and in HPC systems. In all these I've been comfortable that I've been
able to adapt Linux, reconfigure, do what was needed to get it going on
any size of device, and get my changes either accepted upstream,
maintain them locally in my organisation or both. With systemd I don't
think I could do that, and thats very disempowering.

Do I really need to point out that if we lose developers, then the users
lose too?

Alastair

-- 
Alastair McKinstry, , , 
https://diaspora.sceal.ie/u/amckinstry
Misentropy: doubting that the Universe is becoming more disordered. 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54e20c0f.4020...@sceal.ie

Re: how to remove libsystemd0 from a live-running debian desktop system

[Christian Kastner]

On 2015-02-16 13:47, Luke Kenneth Casson Leighton wrote:
> On Mon, Feb 16, 2015 at 11:42 AM, Christian Seiler  wrote:
>> Am 16.02.2015 um 02:54 schrieb Luke Kenneth Casson Leighton:
>>>
>>> http://lkcl.net/reports/removing_systemd_from_debian/
>>
>>
>> It's funny that when Wheezy (not Jessie!) came out, nobody complained
>> that libsystemd-login0 (which is now part of libsystemd0) was as a
>> dependency of dbus, so it is probably already installed on most desktop
>> systems running current Debian stable.
> 
>  i'll hazard a guess that it's because they had no idea that, in the
> very near future, all the major desktop developers and all the major
> distros would make the unilateral decision to hard-code the
> *exclusive* use of systemd (or parts of it).

I'll hazard another guess, namely that the great vast majority of users
simply do not care. I'd be surprised if most users even know what an
init system does, much less what the differences between sysvinit /
systemd / upstart / etc are. [*]

And what do you mean by "unilateral" decision? If you want to be
involved in the design and development of a software, do what everyone
else does -- contribute. That works for everyone else, AFAICT. It's
really becoming tiring to hear this incessant, high-pitched,
full-of-entitlement whine about how the free-as-in-speech software
someone else is putting the time and effort to provide them with is not
acceptable to them. If you know something that all-the-desktops and
all-the-distros don't, then act on that knowledge.

Christian

[*] Anecdotal: the result of a quick poll among 4 Linux users in my
immediate vicinity had just this result.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/aaa2528ab82e1ffd4b465b8d867d0...@kvr.at

Re: how to remove libsystemd0 from a live-running debian desktop system

[The Wanderer]

On 02/16/2015 at 07:47 AM, Luke Kenneth Casson Leighton wrote:

> On Mon, Feb 16, 2015 at 11:42 AM, Christian Seiler
>  wrote:
> 
>> Am 16.02.2015 um 02:54 schrieb Luke Kenneth Casson Leighton:
>> 
>>> http://lkcl.net/reports/removing_systemd_from_debian/
>> 
>> It's funny that when Wheezy (not Jessie!) came out, nobody
>> complained that libsystemd-login0 (which is now part of
>> libsystemd0) was as a dependency of dbus, so it is probably already
>> installed on most desktop systems running current Debian stable.
> 
> i'll hazard a guess that it's because they had no idea that, in the
> very near future, all the major desktop developers and all the major
> distros would make the unilateral decision to hard-code the
> *exclusive* use of systemd (or parts of it).
> 
> my assessment is that it's that total lack of choice that is causing
> people to get so upset.  but there's no need to get upset about it:
> *we didn't know*. nobody could have predicted how far this would go,
> so quickly.
> 
> so the question then becomes: at a fundamental level (in a
> distro-agnostic way) how to go about giving people a proper choice
> (to run systemd and associated components, or not)?

As Russ pointed out in a thread on -project last month: either revive
ConsoleKit, or reimplement logind in a way which isn't dependent on
systemd, and do either or both in a way which is acceptable to all
relevant upstreams (including PolicyKit).

Adam Borowski already mentioned consolekit2 and loginkit, which sound
like attempts to do exactly those two things. I don't know how
successful they would be, but that would be the path to take.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: how to remove libsystemd0 from a live-running debian desktop system

[Luke Kenneth Casson Leighton]

On Mon, Feb 16, 2015 at 11:42 AM, Christian Seiler  wrote:
> Am 16.02.2015 um 02:54 schrieb Luke Kenneth Casson Leighton:
>>
>> http://lkcl.net/reports/removing_systemd_from_debian/
>
>
> It's funny that when Wheezy (not Jessie!) came out, nobody complained
> that libsystemd-login0 (which is now part of libsystemd0) was as a
> dependency of dbus, so it is probably already installed on most desktop
> systems running current Debian stable.

 i'll hazard a guess that it's because they had no idea that, in the
very near future, all the major desktop developers and all the major
distros would make the unilateral decision to hard-code the
*exclusive* use of systemd (or parts of it).

 my assessment is that it's that total lack of choice that is causing
people to get so upset.  but there's no need to get upset about it:
*we didn't know*. nobody could have predicted how far this would go,
so quickly.

 so the question then becomes: at a fundamental level (in a
distro-agnostic way) how to go about giving people a proper choice (to
run systemd and associated components, or not)?

 l.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAPweEDwgsC9nfXfiGnTPuXS9SdJNExqaXhLgdQdPpJ9g=7g...@mail.gmail.com

Re: how to remove libsystemd0 from a live-running debian desktop system

[Adam Borowski]

On Mon, Feb 16, 2015 at 01:54:35AM +, Luke Kenneth Casson Leighton wrote:
> to illustrate the dominance of libsystemd0, if you carry out an
> "apt-get --purge remove libsystemd0"

First, it's actual systemd packages that are a problem, libsystemd0 is
merely a harmless library which does nothing but bloat your system a
negligible bit.

Second, all but one (upower) of affected packages can be recompiled to drop
the dependency.  If you bothered to read lists you're subscribed to, you
would probably know of my set of deinfected packages at:
 deb http://angband.pl/debian nosystemd
 deb-src http://angband.pl/debian nosystemd
which are included for example in Trios.  After such a recompilation, you
can have a systemd-free system with no functionality loss -- in fact, it
does solve some regressions compared to systemd-using hacks like -shim.

Packages in Debian tend to have the biggest possible set of functionality
enabled.  For systemd support, this ends up depending on libsystemd0
(harmless) and "systemd"/libpam-systemd (harmful if it's a strict
dependency).  It's only the second kind that's worth fixing.

This would be easily fixable by runtime detection of systemd.  For example,
in policykit-1 (which most dependency chains go through), systemd and
consolekit code paths are well-separated by upstream into a portable header
and two independent .c files implementing that header.  All that would need
to be done is making a stub that calls the proper implementation on runtime
(as opposed to link time as currently).

The above might be not even needed in the future, as both main proposed
replacements, consolekit2 and loginkit, aim for systemd-compatible API.

> this process comes with a price: i had to disable udev, and i had to
> re-enable the keyboard and mouse sections in xorg.conf that i had
> added years ago.

Bare-metal systems without udev or an equivalent haven't been supported for
ages.  There are multiple projects building a replacement for systemd-udev
for after jessie; for now, udev is built from systemd sources but has no
dependency on it.  Ie, it's swallowed but not yet digested.

-- 
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150216123801.ga10...@angband.pl

Re: how to remove libsystemd0 from a live-running debian desktop system

[Christian Seiler]

Am 16.02.2015 um 02:54 schrieb Luke Kenneth Casson Leighton:

http://lkcl.net/reports/removing_systemd_from_debian/


It's funny that when Wheezy (not Jessie!) came out, nobody complained
that libsystemd-login0 (which is now part of libsystemd0) was as a
dependency of dbus, so it is probably already installed on most desktop
systems running current Debian stable.

Christian


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54e1d789.20...@iwakd.de

Re: how to remove libsystemd0 from a live-running debian desktop system

[Lisi Reisz]

On Monday 16 February 2015 08:09:19 Marco d'Itri wrote:
> > to debian-users: you don't have complete choice (yet), but i have
> > demonstrated with a few hours work that there is a way to run
> > (certain) desktop environments without requiring libsystemd0 or any of
> > its dependencies, and after a little investigation there do appear to
> > be people working hard to give you your right to choose what software
> > to run *without* having to abandon debian.
>
> I strongly recommend that the people who cannot live with libsystemd0
> installed on their systems leave Debian,

Oh, yes, please!  Please.  Please.  You have lots of choice.  There are lots 
of distros and you can fork (devuan).  But leave us in peace!  It has been 
lovely on this list without you lot.

Lisi


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/201502161142.14548.lisi.re...@gmail.com

Re: how to remove libsystemd0 from a live-running debian desktop system

[Jochen Spieker]

Marco d'Itri:
> On Feb 16, Luke Kenneth Casson Leighton  wrote:
> 
>> to debian-developers: the technical issues are irrelevant (and can
>> always be solved over time) - it's that you are complicit in removing
>> people's software freedom right to choose what to run on their system:
>> that is why so many users are upset with you.  and that really is not
>>
> Cool! It has been since my Usenet days that I have not been accused of 
> being part of a conspiracy. Thank you, I missed this.

Really? I thought you already destroyed Linux with your work un udev.
:->

J.
-- 
As a child I pulled the legs from a spider.
[Agree]   [Disagree]
 


signature.asc
Description: Digital signature

Re: how to remove libsystemd0 from a live-running debian desktop system

[Paul Wise]

On Mon, Feb 16, 2015 at 2:52 PM, Russ Allbery wrote:

> Or, alternately, you could research how and why one would use shared
> libraries in a binary distribution to support optional features.  But
> that's boring, prosaic, and nowhere near as much fun to write about.

We were discussing optional libraries on IRC and noticed the Solaris
libc supports this but I can't find any reference to that for glibc.

http://docs.oracle.com/cd/E19253-01/817-1984/chapter3-27/index.html

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAKTje6FPHM7vsUW=d+5x0+uaajjslmomdb7gaj2x816gyny...@mail.gmail.com

Re: how to remove libsystemd0 from a live-running debian desktop system

[Marco d'Itri]

On Feb 16, Luke Kenneth Casson Leighton  wrote:

> to debian-users: you don't have complete choice (yet), but i have
> demonstrated with a few hours work that there is a way to run
> (certain) desktop environments without requiring libsystemd0 or any of
> its dependencies, and after a little investigation there do appear to
> be people working hard to give you your right to choose what software
> to run *without* having to abandon debian.
I strongly recommend that the people who cannot live with libsystemd0 
installed on their systems leave Debian, because their life is going to 
suck more and more as we will integrate it in every important daemon 
after jessie will have been released.

> to debian-developers: the technical issues are irrelevant (and can
> always be solved over time) - it's that you are complicit in removing
> people's software freedom right to choose what to run on their system:
> that is why so many users are upset with you.  and that really is not
Cool! It has been since my Usenet days that I have not been accused of 
being part of a conspiracy. Thank you, I missed this.

> you have the right to choose whether the situation that you are
> complicit in is something that you find acceptable or whether you do
> not.  i leave it entirely to you to decide.
I do not just find it acceptable, I thoroughly enjoy it.

-- 
ciao,
Marco


pgpoEsBqhWUyF.pgp
Description: PGP signature

Re: how to remove libsystemd0 from a live-running debian desktop system

[Russ Allbery]

Luke Kenneth Casson Leighton  writes:

> i've documented the process by which it is possible to run some of the
> debian desktop window managers (TDE, fvwm, twm etc.) without the need
> for systemd or libsystemd0 or any components related to systemd
> whatsoever.

Alas, the resulting distribution is still hopelessly compromised by the
NSA, who might be even worse than Lennart Poettering.  To see how deep the
tendrils of US government infiltration go, just try removing libselinux1,
and marvel at how much concerted malevolent effort has gone into
destroying your freedom.

Or, alternately, you could research how and why one would use shared
libraries in a binary distribution to support optional features.  But
that's boring, prosaic, and nowhere near as much fun to write about.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87vbj2e4bh@hope.eyrie.org

Re: how to remove libsystemd0 from a live-running debian desktop system

[Josh Triplett]

Luke Kenneth Casson Leighton wrote:
> to debian-developers: the technical issues are irrelevant (and can
> always be solved over time) - it's that you are complicit in removing
> people's software freedom right to choose what to run on their system:

People still have that right, just as they have the right to run a
system without glibc, PAM, or libpng; in all of those cases, they'll
have to do some work to do so, and they shouldn't expect any significant
support from developers for the result.

Consider toning down the hyperbole if you actually care about convincing
anyone who doesn't already agree with you.  You're currently complaining
at the developers of one of the only distributions to actually still
make it an *option* to use systemd, rather than making it mandatory.  In
particular, anyone following systemd development can easily see the
substantial volume of work that Debian's systemd maintainers have
generously done to *accomodate people who don't want to run their
software*, as well as the substantial effort this puts on people
maintaining the surrounding packages to cope with such configurations.
All while dealing with a regular stream of flames and vitriol about
their work.

> and that really is not
> a judgement, it's simply an insightful summarising statement of fact:

"insightful", really?  Do you think yet another thread on debian-devel
really added any significant value?  And apparently "users who don't
like systemd" was an insufficiently niche group, so instead you're
starting a thread on behalf of the subset of those users who find the
very sight of the string "systemd" in their package list revolting even
when prefixed by "lib".

> you have the right to choose whether the situation that you are
> complicit in is something that you find acceptable or whether you do
> not.  i leave it entirely to you to decide.

"The situation" being a pile of packages that depend on a 183k library,
while going painfully out of their way to avoid any actual dependencies
on systemd as the init system?  Oh no, it's a sign of the imminent
apocalypse. 

I for one look forward to the day when configurations without systemd as
the init system finally become so unsupportable that packages can start
actually using systemd features without fear of reprisal, or at least
shift the maintenance burden of such configurations to people who
actually run them and care about them.

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150216043638.GA25449@thin

how to remove libsystemd0 from a live-running debian desktop system

[Luke Kenneth Casson Leighton]

http://lkcl.net/reports/removing_systemd_from_debian/

i've documented the process by which it is possible to run some of the
debian desktop window managers (TDE, fvwm, twm etc.) without the need
for systemd or libsystemd0 or any components related to systemd
whatsoever.

the process is not without difficulties, however out of (at the time
of writing) only two people who have followed this procedure, i was
the one that ended up having to disable udev: the other individual had
a working system (devoid of libsystemd0) purely by following only the
instructions to alter and replace bsdutils from the util-linux
package.

the reasons for demonstrating that this is possible have absolutely
nothing to do with my *personal* (technically-based) dislike of
systemd, although my reasons for actually removing libsystemd0 from
personal systems *are* based on a technical assessment (mostly with a
sysadmin eye).  but, i repeat: my *personal* choice has *nothing to
do* with the reason for posting this documentation.

the reason for demonstrating that this is possible is because nobody
has yet made it clear to either the upstream developers - or to the
distro maintainers who unfortunately are caught in the crossfire -
that systemd's unilateral adoption  is fast becoming an
"all-or-nothing" polarised choice that reminds me keenly of the
polarised Microsoft Monopoly power and dominance of the late 1990s.

and that *really is it*.  the technical issues are completely
irrelevant: those can and will be solved.  already we have evdev,
mdev, devuan, uselessd and many more, but those technical options are
*COMPLETELY SHUT OUT* by the exclusive - monopolistic - position that
systemd now has.

to illustrate the dominance of libsystemd0, if you carry out an
"apt-get --purge remove libsystemd0", *all* of the packages and many
more on the following PNG will be removed:

http://anfo.slavino.sk/libsystemd-journal0.png

that list is woefully incomplete, so i have generated a current list
using apt-rdepends -r libsystemd0 | some manual magic | sort | uniq.
http://lkcl.net/reports/removing_systemd_from_debian/list_of_libsystemd0_dependent_packages.txt

the list is a whopping 4,583 packages (from the current
debian/testing).  apache2-dev, androidsdk, apt-cacher-ng,
avahi-daemon, blender, bluetooth, bochs, cairo-dock, calligra,
consolekit, cups-daemon, cups-core-drivers, cups-driver-gutenprint,
dbus - this is just a few major software libre packages i can see in
the the first 9% of the list that are affected (cannot be installed)
should anyone exercise their right to choose *not* to have libsystemd0
on their machines.

even dh is on the list.  erlang is on the list!  kde, gimp, xfce,
lxde, gnome, libreoffice, xine, mediawiki, mplayer, network-manager,
openjdk-7, phonon, php (??? why is php dependent on libsystemd0??),
pidgin, policykit-1, postfixadmin (??), pulseaudio, qemu, syslog-ng,
vlc, wicd (client and server), xbase-clients (??), x11-apps (??),
xbmc, xchat... those are just ones that i recognise out of the 4,500+
packages that are not permitted to be installed.

so the short and long of it is: i do not like it when people are not
given the freedom to choose...  and that includes when, just like when
microsoft was so dominant in the 1990s, the choices they are presented
are not really a choice at all.  what i have done therefore is to show
how to modify the debian packages for policykit-1, dbus, pulseaudio
and util-linux, such that libsystemd0 may be entirely removed.
removal of libsystemd0 from those packages trims that list of several
thousand unilaterally-excluded packages *significantly*.

this process comes with a price: i had to disable udev, and i had to
re-enable the keyboard and mouse sections in xorg.conf that i had
added years ago.  however, already within hours of the report's
publication i have received word from one other person who did *not*
have the same extensive difficulties that i encountered: udev
(unmodified) worked perfectly for them.  in a follow-up message they
did however explain that they have successfully installed and then
removed (at an earlier point) a source-compiled version of mdev, which
illustrates that they have some quite significant experience in
maintaining a hybrid of standard debian packages and system-critical
packages compiled directly from source.

so, in short, i have two key things to say.

to debian-users: you don't have complete choice (yet), but i have
demonstrated with a few hours work that there is a way to run
(certain) desktop environments without requiring libsystemd0 or any of
its dependencies, and after a little investigation there do appear to
be people working hard to give you your right to choose what software
to run *without* having to abandon debian.

to debian-developers: the technical issues are irrelevant (and can
always be solved over time) - it's that you are complicit in removing
people's software freedom right to choose what to run on their system:
that is why so many users