[gentoo-dev] Re: Any official position from Gentoo about systemd, mdev and udev-static ?

[Duncan]

Walter Dnes posted on Wed, 29 Aug 2012 21:19:13 -0400 as excerpted:

>  Note that a fork will have to be be "bug-compatable" to Redhat's
> version, just like DR-DOS had to be bug-compatable to MS-DOS, way back
> when.  And what happens when that "compatability" requires not just
> systemd and dbus but pulseaudio and binary syslogs and whatever else the
> Redhat developers decree?

FWIW... in my web wanderings I came across a discussion (on G+ I think) 
where, I believe it was Ted T'so mentioned talking to one of the RHEL 
product engineers... and they're not entirely happy with all the desktop 
stuff, binary logs, etc the combined udev/systemd is pulling in and doing 
these days, either!  After all, they're supporting a product for 
something like 10 years, that is often used in an enterprise server 
environment where the full desktop may not actually be installed -- or at 
least that's the way it *WAS*.  They could ignore pulse-audio in that 
regard, because such servers often didn't have/need sound anyway.  But 
they're not too happy about this whole dragging in the whole desktop 
thing, NOR about potentially having to support "the latest hot fad" 
someone dreamed up (even if that someone's actually a RH employee) for a 
decade!

Remember hal?  They're still dealing with that!

Anyway, it's generally accounted to Red Hat's credit that they don't 
interfere too much with the development policies of the projects they 
sponsor people to work on, but that doesn't necessarily mean even Red 
Hat's particularly happy with said policies!

Based on that discussion, I'd say that while Red Hat will hopefully 
continue its in general non-interference with projects it sponsors 
policies, there's at least SOME possibility that they'll either work 
around the problem in their coming releases with patches then available 
to the community, or interfere albeit in an arguably "least harm" 
fashion, by eventually mandating at least branches (from which they'd 
pull), that at least make some of these sorts of dependencies optional.

Or maybe they'll actually sponsor a fork too, if they have to.  But I 
doubt it'll come to that.

Regardless, coming RHEL releases may not end up being as drastically 
integrated in this regard as the current trend, which is after all now at 
the Fedora level not RHEL level, would indicate.  It DOES remain to be 
seen, but that thread gave me at least SOME hope that the ENTIRE
(Gnu/)Linux world (other than Gentoo and Debian, maybe) hasn't gone mad, 
as well as an explicit awareness that Red Hat is now a large enough 
company (just hitting a billion a year, right?) that like many large 
companies, the right hand and the left hand, separated into their own 
departments, may be working toward not entirely compatible ends.

It'll be interesting to see how it all plays out, when the big dollars 
feeding red hat come in conflict with some of the policies of some of 
their sponsored projects and employees, corporate hands-off policy or no 
corporate hands-off policy.

But one thing's for sure, there's money there, and where there's that 
sort of money involved, one way or another, the code usually "appears".  
So all is not YET lost, regarding "insane" dependencies at the base udev 
level.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman