C de-Avillez schreef op 21-07-2016 22:19:
But here you are referring to a mail thread on systemd-devel, and
ranting about how people that know what they are talking about (and
even tried to argue with you about it) do not agree with you.
I never said they didn't know what they are talking about. I said they
apparently, evidence themselves, to have reasons, to deny the needs of
real individual users, and favour only a select group of users that have
needs that are now being met in some mediocre way (according to me, but
I am sure a lot of people will agree with it) while costing all of those
other people a whole lot, and then these costs are being downplayed and
these benefits are being exaggerated.
Whenever something like that happens you just know something is fishy.
But just as the kernel developers are rumoured not to put up with
bullshit, neither should I be expected to (or anyone).
So, no, this thread *is* important. It puts your comments in context.
https://www.mail-archive.com/systemd-devel%40lists.freedesktop.org/msg35744.html
Actually that was the second thread, apologies. I had forgotten there
were two. That is also an annoying archive and it cost myself a great
deal to find one that actually works, which is the main archive :p.
the threads (both of them, but I guess they are only one) are at
https://lists.freedesktop.org/archives/systemd-devel/2016-April/thread.html
and you can find them easily if you scroll down.
And, still, you antagonise people because you think they do not see
your PoV. You succeeded in getting Martin uninterested in discussing
this further with you.
You mean here? That is of no consequence. The discussion ended with Greg
KH trying to explain to me that hardware was event driven and that as
such devices could only make their presence known using events, as if
speaking to a child, whereas *apparently* device drivers actually poll
for devices (we were only talking about "onboard" devices here) and if
they can't find any they quit - there is no wait time here that can
suddenly extend for hours.
He even tried to explain to me that if hardware changes between boots
(e.g. you add or remove hardware) that it would require "events" for the
system to be notified about those changes.
Now you can stretch things very far but the system does not produce
events while powered off.
But the only way I would get some truth on this (from my perspective)
was apparently to just dive into the source code of some ethernet driver
and see what it did.
At the same time they were /insisting/ that hardware can show up hours
after booting the system (have you ever seen that happen, for onboard or
physically-present devices?) and that as such, not only in a theoretical
but also practical manner, the discovery phase of onboard hardware never
ends, and that it therefore would be conceptually impossible to define
any such end-point.
I'm sorry but I just don't like to be bullshitted in that way. It is
completely obvious for any practical system such as my own, that all
hardware is found within seconds.
So I don't know why this "theoretical implication" is important and they
never revealed this, as such it was nothing more than a knock-down
argument.
Greg apparently insisted on talking in hypotheses and never alluded to
any real-world example. And based on this conceptual truth that was only
demonstrated by talking about event-driven-hardware, where device
drivers actually poll for hardware and if any events ever result from
that, it is likened to a callback measure, and apparently very
well-bounded in time (in any practical ,real system), based on this
conceptual truth I was then supposed to accept that in practical terms
any definition of an end-point in device discovery (for onboard devices,
not usb or thunderbolt) would be unviable.
When it is completely obvious that in any real and functional system as
we have today your hardware will be discovered within seconds. Many
people alluded to having boot times measured in seconds for their
systems.
If you can boot to your desktop in 5 seconds I am sure you can also
discover your network devices within any bounded timeframe.
But I am repeating myself now.
They gave no good reason why a division in phases (device discovery,
name remapping, network starting) would not be possible.
Other than by pointing to vague ideas of why it wouldn't work, refusing
to become concrete with their statements, and keeping everything "up in
the air" as to why it wouldn't work. I am a programmer myself and yes I
did study operating systems although it was long ago.
If I don't understand something I like to get down to the core of it as
to why that is so. And these answers did not suffice.
Now perhaps no one ever has a need or requirement to please this here
person that I am, but that is not important.
The first three messages in the entire thread were these, and please
apologize my verbosity back then:
https://lists.freedesktop.org/archives/systemd-devel/2016-April/036172.html
https://lists.freedesktop.org/archives/systemd-devel/2016-April/036174.html
https://lists.freedesktop.org/archives/systemd-devel/2016-April/036175.html
That's me, Martin Pitt, and Andrei Borzenkov, whom I consider to be
pretty knowledgeable as well.
I think that if you want to get a "digest" of what that was about, you
should only read those 3, and maybe skip half of what I have said myself
;-). But Andrei ... is a regular on that list as well and Knows like
Everything. And Andrei himself did not agree with the rebuttals given by
Martin.
Reindl Harald also gave a succint commentary on the words of Mr. Pitt:
https://lists.freedesktop.org/archives/systemd-devel/2016-April/036177.html
In the end, what it came down to was:
- the people in favour think configuring the system now is easy
- Mr. Borzenkov said this was insincere as the required infrastructure
had been taken out (alluding to
/lib/udev/rules.d/75-persistent-net-generator.rules that has been taken
out including its accompanying script)
- Mr. Pitt voiced the argument that they had a responsibility to make it
work for everyone by default
- Mr. Pitt also voiced the argument that people should not be expected
to need to configure their system.
However the people that actually need the new functionality have
multiple NICs and as such need to configure network roles; as such they
always are required to configure their network.
The people that never needed to configure their network before now have
a dysfunctional system with names that change whenever hardware is
changed. Names that are going to be different from system to system.
Scripts that need to be tailored to every system in isolation or just
read the current configured NIC through wildcard resolution e.g. the ls
/sys/class/net/enp?s0 -d that was alluded to. As such these people have
a real need to get rid of this system, which mr. Pitt downplayed by
saying that they don't "need" to do it and (I guess) that most "desktop
users" would never "look under the hood" or something to that sentiment.
In other words, if you can shield people from this system, they will
also not know about it, nor find a reason to change anything about it.
I want to thank Martin Pitt for helping me solve my own issue (once
again :P) in responding to this thread in a practical manner.
I mean, if you say it is easy, you've gotta make it so. But for me the
burden of proof lies with the people that want this system the way it
has been made today.
You know, after a "preponderance of evidence" ;-),
* the default is tailored to a minority (less than 1% of Linux systems)
* the majority does not benefit from the default, but in fact finds
great detriment from it
* the only way to downplay the detriment is to insist that most people
will never need to change the system (since they use DHCP) or that the
ones that do, will be able to after a bit of research.
The question of what is right, or just, is not asked.
The question of why this feature is so important that pretty much
everyone else needs to suffer, is not asked.
The question of why this feature is so essential that it needs to be
made the default, in retrospect of many users who find that reverting
the change is nearly impossible for them, or too troublesome to want to
deal with, seeing as it doesn't impact them much other than visually,
and in terms of pleasantness, and in terms of familiarity, and in terms
of being happy about it, is not asked.
I want to explain that by saying that as a user who does care, reverting
the change is not trivial if you don't want to use kernel parameters,
and often not important enough to warrant rebooting the system for. That
seems to indicate that it is not that important after all. No, but it
annoys the hell out of you until it does become important, and you
usually try to put that moment off as long as possible.
So you are constantly looking at something that is important enough to
care, but just not important enough to deal with instantly.
It's like that dripping tap you need to repair. It is not something that
ruins your day or to sidetrack something else for, but it drives you
nuts and now all houses come standard with dripping taps.
Because one in a million people needs a dripping tap.
This is the end of the thread, for me as well. But the other
subscribers
should have the source.
Which is exactly why I called you insincere. You are not asking for the
reference because you are interested, but because you feel others should
not be interested in my words.
I am not interested in breaking anyone down. I am, though, interested
in
understanding what is going on.
Sure.
I think actually we can meet each other there, because there are a whole
lot of people who wonder what is going on.
With the interface device names and why they needed repair.
--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
