Re: Keep using Debian without GNOME and SystemD
On 22/10/2014 7:06 μμ, Martin Read wrote:
On 22/10/14 08:37, Dimitrios Chr. Ioannidis wrote:
What details do you think are neccecary ?
Just grab a DI-b2 img, install xfce or lxde ( with the menu or with
desktop= .... doesn't matter ) and then try to remove *all* the systemd
utilities / libraries etc.
dbus-daemon is linked against libsystemd in Debian jessie. That's not
going to change at this point.
The Debian package of xfconf (XFCE's configuration mechanism) depends
on the package 'dbus-x11', which depends on the package 'dbus' (the
one that contains dbus-daemon), implying that it requires a working
dbus-daemon for correct operation.
Looking at the upstream website for XFCE, I see that xfconf lists dbus
as a *non-optional* dependency.
(This is leaving aside the whole matter of one of the programs in the
essential package 'bsdutils' now being linked against libsystemd as a
result of a perfectly reasonable decision.)
This is getting nowhere ...
I tend to agree to the following post
"... the goal is to avoid making a derivative work. The GPL describes
various ways to recognise a project as having "derived" from covered
code, and linking copyleft and proprietary code together is one of them.
(with some variation depending on if we are talking GPL or LGPL).
Remember that one of Poettering's goals is, in his own words
[0pointer.net], "... the primary interfacing between the executed
desktop apps and the rest of the system is via IPC (which is why we work
on kdbus and teach it all kinds of sand-boxing features)".
The point is if I want to do (for example) some sort of user
authentication, I may have to link against libpam.so. This is something
that would be reasonably commoon in embedded systems, and linking
covered code into your embedded device (and having to distribute
libpam.so with your product) could easily be a derivative work. (details
matter, ask your lawyer about specific projecs).
Once absorbed into Poettering's project, you avoid all that risk because
you don't interface with the system features directly and instead use
"local RPC". This changes the project from being a potentially
infringing derivative work into something that merely uses the tool.
Merely using a tool that is licenced under the GPL is explicitly
excempted, as the GPL only coveres redistribution and not use. ("GPL is
not an EULA") This is a major change in legal status for your typical
embedded device, which often wants a minimal OS to host their embedded
app. They would also really like to avoid having to deal with the
handling anything GPL. Changing to "local RPC" for all system
interaction neatly fixes that problem.
We don't run across this pattern with traditional RPL tools, because
it's bad for performance to needlessly serialize everything when you
could simply call a function directly."
regards,
--
Dimitrios Chr. Ioannidis<d.ioannidis@nephelae.eu>
Nephelae
Reply to: