On 11/17/2014 01:54 PM, Ludovic Meyer wrote:
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.
There *are* people doing it, e.g. systemd-shim, uselessd, nosh and
eudev, the refracta team, and others. There are so many projects, it's
hard to know where to join in, but I'm willing to help if I can.
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 ?
Right now Jessie is seems to have acceptable sysvinit support. The main
concerns seem to be about Stretch, but that's 3-4 years away, so I think
there's time to work on solutions.
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.
Keep in mind this is a mostly volunteer project, with a lot of people
working in their spare time.
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.
I think small teams are the way to go in FOSS.
>>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.
It's a philosophy, and not even the dominant one in the software
industry, but it is about technology and engineering, and part of the
culture and design of Debian. I recognize that it also clashes with the
"universal operating system" moniker, because the whole world is not
Unix, so I see a place in Debian for monolithic OSs like systemd and
Android clones, but I would have been more conservative about
introducing it.
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".
Design philosophies have major technical implications. If Debian had
started with Windows 3.1, I don't think the project would be where it is
today. Loose package coupling works well with volunteer projects. For
systemd to work in Debian it has to work within the existing modular
framework, and I think it can be done, with difficulty.
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.
You forgot to include lispm and Plan 9. The ancient trappings are more
like relic than Interesting debate, but to me Unix Philosophy is just
the maxim “everything should be as simple as possible, but not simpler.”
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.
It's slow and messy, but you can't argue with success. I don't want a
poor man's OS-X, and I'm not waiting for the "year of the Linux
desktop." My desktop works fine (after I purge Gnome).
>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.
Already done:
https://lists.debian.org/debian-ctte/2014/02/msg00447.html
debian-ctte, debian-vote and debian-devel may be the best lists to catch
up on the systemd debate.
>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.
Or solve the problem in a better way. I don't hear him saying there's no
solution.
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.
So he wants the opposite of unix philosophy and that is what the clash
with Debian is about, in a nutshell.
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.
If they improve their social skills they may get a workable solution.
Handling high-volume traffic is where the kernel shines.
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.
Comparing anything in user space to the kernel seems like a stretch, but
I wish them luck. In the meantime tone down the "unified solution"
rhetoric because I don't think Debian is looking for a Linus to run the
project by proxy.
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.
I think they may be regretting it now that the overhead is paid in
debugging hours, but Linux started as a hobby project, "nothing big and
professional like GNU."
And with that, I think I just set a personal record for longest post. :)
--
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/546abcec.7010...@ix.netcom.com
