On 11/16/2014 03:32 PM, Ludovic Meyer wrote:
On Sun, Nov 16, 2014 at 01:05:08PM -0500, Marty wrote:
<snip>
My point is that in a modular design nothing should be so entrenched
as to be irreplaceable. Absence of an alternate should not normally
indicate impossibility of an alternate, but some discussions I've
read about logind, udev and dbus are enough to raise serious
concerns.
The problem is that, without any action, the difference between "nothing
can be replaced" and "it can be replaced" is purely theorical.
The problem is very real, but there seems to be no agreement about
solutions, which by itself is evidence of a problem.
Now you
can discuss for years in theory,
In fact, people have been discussing this problem for years.
if this doesn't result in any practical
outcome, you have just stresstested the mailling lists software.
Until there's a rough consensus and a clear way forward, I don't think
many people will commit to specific solutions. There are also unknowns
like kdbus, to further complicate the matter.
People who just say, "write your own, it's all FOSS" are missing the
point, I think. Debian is not one guy working in his mom's basement.
It's one of the world's largest software projects. When Debian is
stumped, because its best developers and upstreams are caught in the
entanglement hairball, and see no clear way out, the it's clear case
of *Houston we have a problem.*
That's a interesting point, because with all those brillant minds,
a vast majority do not even seems to care about this
"entanglement hairball". Maybe it is time to admit you do not
know the whole details and accept that if developpers do not care,
then they are maybe right in doing so ?
Especially since you have been unable to give any technical reasons
to why you do not want it, and how you would proceed.
For you, I would start by explaining the Unix Philosophy and how it is a
critical aspect of Debian's design:
http://en.wikipedia.org/wiki/Unix_philosophy
Then I would proceed to explain how various aspects of systemd conflict
with this, causing said hairball. Finally, I would explain (to the best
of my ability) how the entanglement issue precludes a quick resolution,
and the delay does not indicate lack of interest.
In fact, a quick google check would even give you the required
knowledge of why it is better to link :
http://spootnik.org/entries/2014/11/09_pid-tracking-in-modern-init-systems.html
You can compare the code with "link to systemd library" vs "cut and
paste in every source code". As a exercise, you can
surely add "use dlopen()" and see which one is simpler and easier to maintain
in the long term.
Then it will be your turn to explain why it is better to cut and paste or
link statically the library, or why it is better to have to patch every upstream
to use dlopen().
Not sure how we went from entanglement issues to PID tracking, but
granting your point, it still doesn't explain how we arrive at kdb,
console and qcodes in PID 1. :)
And once you will have been able to justify that on a technical level,
maybe people will start to listen to you.
For the record, see also the discussion on
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=555980
You did not make much of a case for a complex PID 1 process, and on that
question I defer to a kernel dev who takea a rather dim view of it:
http://lwn.net/Articles/618024/
--
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/54694f78.6090...@ix.netcom.com
