Lars Noodén <lars.nooden@???> writes:
> On 02/13/2016 09:10 PM, KatolaZ wrote:
>> On Sat, Feb 13, 2016 at 09:30:16PM +0300, Jack L. Frost wrote:
> ...
>
>>> [0]: http://asay.blogspot.ru/2006/10/interview-with-red-hat-cto-brian.html
>>
>> Am I wrong or that interview is from almost 10 years ago? :)
>
> It is. But they seem to have followed through on that threat to add
> lots of complexity.

There's no such threat in the interview (which isn't really an interview
at all, just a from-memory transcription of an interview Asay made),
just a statement some RedHat CTO made in 2006 that he believed
supporting an operating system was more likely to be a viable business
model than supporting a web server because the operating system was way
more complex than a web server.

The 'RedHat' engineering concept (also outlined in this article) of
"hire CS graduates and let them do whatever they want" is bound to
lead to a load of badly written, overly complicated software for solving
simple problems with already had entirely satisfactory solutions but
that's not "a conspiracy", just ill-conceived management.

Eg, something like this

https://dvdhrm.wordpress.com/2015/06/20/from-af_unix-to-kdbus/

is surely not "a RedHat originated conspiracy".

This text claims to be about kdbus but it basically doesn't mention it
at all beyond asserting the something claimed to be comparable would be
"fundamentally flawed" (my words) and kdbus the magic fix for it, no
technical details provided on that.

But it contains a nice example of "cargo cult programming": Sending
messages to an AF_UNIX SOCK_DGRAM socket via

sendto(fd, "foobar", 7, MSG_NOSIGNAL, (struct sockaddr*)&destination, sizeof(destination));

In 2010, a certain Lennart Poettering was going through the dbus
(daemon) code replacing every send call with one specifying MSG_NOSIGNAL
in order to avoid SIGPIPE signals when trying to write to a 'broken'
virtual circuit[*] reported by Scott James Remnant in a blob entry
which has since vanished from the web, he overlooked at least one which
cause the dbus daemon to die suddenly (and the upstart test suite
detected this). As shown above, this seems to have developed a life of
its own in the meantime: MSG_NOSIGNAL serves absolutely no purpose for
a datagram socket, especially an unconnected one.

[*] The sane way to handle this would be to set the disposition of
SIGPIPE to SIG_IGN and make sure to handle EPIPE errors.