On Sun, Nov 16, 2014 at 08:29:28PM -0500, Marty wrote: > 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.
There is not even anyone keeping a list of the solution or even the problem. Even the basis are not done. If you truly want to iterate on a solution, you should start doing it and document it. > Now you > >can discuss for years in theory, > > In fact, people have been discussing this problem for years. And how did it change anything ? It didn't. So what make you think that yet another year is gonna result in something ? I do not want to be too critical, but that's the exact problem that the troll in the Hobbit face, by discussing endless on how to cook the dwarfs, they get petrified. And maybe the time to test and get something wrong, as itcan hardly be slower than discussing. The whole agile methodology. > 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. "Talk is cheap", as Linus said. You seems to be in favor of design by comitee, but this doesn't seems to work for now. > >>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 That's not a technical reason. > 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. And how would that be a technical reason ? If you disagree with the philosophy, that's not a technical problem. That's just a opinion. Show a real technical issue, not "here is the design decided 20 years ago and that was ignored by several others components". heck, even in 1989, people wrote "the unix hater handbook" to explain how the philosophy is wrong. For example, the example of cat not being following this design anymore. No one throw a fuse over it, despites being here, documented and visible by all since more than 20 years. And I know Debian has popularized the idea of "release when it is ready", but that's also the exact definition of vaporware. And people do not even have a estimation of the work. Not knowing what solution to choose do not preclude from saying the time one of them would take. In fact, it would even help to choose. > >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. :) Because the blog post say how and why stuff requires to be linked with systemd. As you didn't explain what you mean by hairballs ( ie, what requires exactly you are speaking about ) it is hard to explain it. I am sure that if you were precise, it can be explained or it could be seen as a bug. > >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 That was not my point. But you just did. > and on > that question I defer to a kernel dev who takea a rather dim view of > it: http://lwn.net/Articles/618024/ So all viro think that : - kernel is not the place for doing interprocess communication at the scale required by systemd. - dbus is not the right place either. his point is that sending too much informations is gonna be a problem anyway. Either by the kernel, or outside of the kernel. so the only way left is to not do IPC, so having everything in the same process. So he is in fact in favor of having a complex process communicating with himself and doing everything. We can see that in the design of the kernel, because of the original design decision of not going the micro kernel way ( ie, minix, hurd ) by Linus, as documented in the debate between him and Andrew Tannenbaum. I would suggest, when you point to kernel developpers, to keep in mind that they work on a big entangled code base, without any internal interface. They kinda endorse that model, or would be working on the hurd. And that's because people keep referring to Linus or others and at the same time complain about systemd that some people do not take anti systemds crowd seriously. The whole kernel design is monolithic, because there is a overhead of doing the other way. So yeah, Al Viro point in favor of a more monolithic and complex solution. -- l. -- 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/20141117185445.gb31...@gmail.com
