The Simple Things in Life

[Xen]

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.