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
